idnits 2.17.1 draft-ietf-httpbis-semantics-17.txt: -(10969): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(10973): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 11 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC7230, but the abstract doesn't seem to directly say this. It does mention RFC7230 though, so this could be OK. -- The abstract seems to indicate that this document obsoletes RFC7615, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC7538, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC7694, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC7615, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7538, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7231, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7232, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7233, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7694, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC7235, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3864, updated by this document, for RFC5378 checks: 2001-09-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 July 2021) is 1006 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2145' is defined on line 9483, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 9507, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 9590, but no explicit reference was found in the text == Unused Reference: 'RFC7617' is defined on line 9619, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-17 -- Possible downref: Normative reference to a draft: ref. 'CACHING' ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch' -- Duplicate reference: RFC2978, mentioned in 'Err5433', was also mentioned in 'Err1912'. -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Duplicate reference: RFC2978, mentioned in 'RFC2978', was also mentioned in 'Err5433'. -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7538 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7615 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7694 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed. 5 7538, 7615, 7694 (if approved) Fastly 6 Updates: 3864 (if approved) J. Reschke, Ed. 7 Intended status: Standards Track greenbytes 8 Expires: 27 January 2022 26 July 2021 10 HTTP Semantics 11 draft-ietf-httpbis-semantics-17 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is a stateless application- 16 level protocol for distributed, collaborative, hypertext information 17 systems. This document describes the overall architecture of HTTP, 18 establishes common terminology, and defines aspects of the protocol 19 that are shared by all versions. In this definition are core 20 protocol elements, extensibility mechanisms, and the "http" and 21 "https" Uniform Resource Identifier (URI) schemes. 23 This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 24 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions 25 of RFC 7230. 27 Editorial Note 29 This note is to be removed before publishing as an RFC. 31 Discussion of this draft takes place on the HTTP working group 32 mailing list (ietf-http-wg@w3.org), which is archived at 33 . 35 Working Group information can be found at ; 36 source code and issues list for this draft can be found at 37 . 39 The changes in this draft are summarized in Appendix C.18. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 27 January 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 87 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1.2. History and Evolution . . . . . . . . . . . . . . . . . . 10 89 1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 11 90 1.4. Specifications Obsoleted by this Document . . . . . . . . 12 91 2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12 93 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 13 94 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14 95 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15 96 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 97 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16 98 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 99 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17 100 3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 101 3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18 102 3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18 103 3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19 104 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20 105 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22 107 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23 108 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23 109 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24 110 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25 111 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25 112 4.2.3. http(s) Normalization and Comparison . . . . . . . . 26 113 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27 114 4.2.5. http(s) References with Fragment Identifiers . . . . 28 115 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28 116 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28 117 4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29 118 4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30 119 4.3.4. https certificate verification . . . . . . . . . . . 31 120 4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32 121 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 33 123 5.2. Field Lines and Combined Field Value . . . . . . . . . . 34 124 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34 125 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35 126 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35 127 5.6. Common Rules for Defining Field Values . . . . . . . . . 37 128 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37 129 5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 38 130 5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38 131 5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39 132 5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39 133 5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 40 134 5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40 135 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 41 136 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41 137 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43 138 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44 139 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45 140 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46 141 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46 142 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 47 143 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 48 144 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 49 145 6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49 146 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50 147 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 51 148 7.1. Determining the Target Resource . . . . . . . . . . . . . 51 149 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 52 150 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 52 151 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 52 152 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 53 153 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 53 154 7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 53 155 7.5. Response Correlation . . . . . . . . . . . . . . . . . . 54 156 7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 54 157 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 55 158 7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 56 159 7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 57 160 7.7. Message Transformations . . . . . . . . . . . . . . . . . 59 161 7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60 162 8. Representation Data and Metadata . . . . . . . . . . . . . . 62 163 8.1. Representation Data . . . . . . . . . . . . . . . . . . . 62 164 8.2. Representation Metadata . . . . . . . . . . . . . . . . . 62 165 8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 63 166 8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 64 167 8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 64 168 8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 65 169 8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 65 170 8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 66 171 8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 67 172 8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 67 173 8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 67 174 8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 67 175 8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 68 176 8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 69 177 8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 70 178 8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 72 179 8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 73 180 8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 74 181 8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 75 182 8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 75 183 8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 76 184 8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 77 185 8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 78 186 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated 187 Resources . . . . . . . . . . . . . . . . . . . . . 78 188 8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 79 189 9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 190 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80 191 9.2. Common Method Properties . . . . . . . . . . . . . . . . 83 192 9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 83 193 9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 84 194 9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 85 195 9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 85 196 9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 85 197 9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 86 198 9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 87 199 9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 88 200 9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 91 201 9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 93 202 9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 94 203 9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 95 204 10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 96 205 10.1. Request Context Fields . . . . . . . . . . . . . . . . . 96 206 10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 96 207 10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 98 208 10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 99 209 10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 100 210 10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 101 211 10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 101 212 10.2. Response Context Fields . . . . . . . . . . . . . . . . 102 213 10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 102 214 10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 103 215 10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 104 216 10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 105 217 10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 106 218 11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 106 219 11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 106 220 11.2. Authentication Parameters . . . . . . . . . . . . . . . 107 221 11.3. Challenge and Response . . . . . . . . . . . . . . . . . 107 222 11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 108 223 11.5. Establishing a Protection Space (Realm) . . . . . . . . 109 224 11.6. Authenticating Users to Origin Servers . . . . . . . . . 110 225 11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 110 226 11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 111 227 11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 111 228 11.7. Authenticating Clients to Proxies . . . . . . . . . . . 112 229 11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 112 230 11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 112 231 11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 113 232 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 113 233 12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 114 234 12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 115 235 12.3. Request Content Negotiation . . . . . . . . . . . . . . 116 236 12.4. Content Negotiation Field Features . . . . . . . . . . . 116 237 12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 117 238 12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 117 239 12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 118 240 12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 118 241 12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 118 242 12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 120 243 12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 121 244 12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 123 245 12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 124 246 13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 125 247 13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 126 248 13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 126 249 13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 128 250 13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 130 251 13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 131 252 13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 133 253 13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 134 254 13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 134 255 13.2.2. Precedence of Preconditions . . . . . . . . . . . . 135 256 14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 137 257 14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 137 258 14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 138 259 14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 139 260 14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140 261 14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 142 262 14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 143 263 14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 145 264 14.6. Media Type multipart/byteranges . . . . . . . . . . . . 145 265 15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 147 266 15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 148 267 15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 149 268 15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 149 269 15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 149 270 15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 150 271 15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 150 272 15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 151 273 15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 151 274 15.3.4. 203 Non-Authoritative Information . . . . . . . . . 151 275 15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 152 276 15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 152 277 15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 153 278 15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 154 279 15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 154 280 15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 156 281 15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 156 282 15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 159 283 15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 160 284 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 160 285 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161 286 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 161 287 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 162 288 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 162 289 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 162 290 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163 291 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 163 292 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 163 293 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 163 294 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 164 295 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 164 296 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 164 297 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165 298 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 165 299 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 165 300 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 165 301 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166 302 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 166 303 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 166 304 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167 305 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 167 306 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 167 307 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 167 308 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 168 309 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 168 310 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169 311 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 169 312 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 169 313 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 169 314 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 170 315 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 170 316 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 170 317 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 170 318 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 171 319 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 171 320 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 171 321 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 171 322 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 172 323 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 172 324 16.1.2. Considerations for New Methods . . . . . . . . . . . 172 325 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 173 326 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 173 327 16.2.2. Considerations for New Status Codes . . . . . . . . 174 328 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 175 329 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 175 330 16.3.2. Considerations for New Fields . . . . . . . . . . . 176 331 16.3.2.1. Considerations for New Field Names . . . . . . . 177 332 16.3.2.2. Considerations for New Field Values . . . . . . 178 333 16.4. Authentication Scheme Extensibility . . . . . . . . . . 179 334 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 179 335 16.4.2. Considerations for New Authentication Schemes . . . 179 336 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 181 337 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 181 338 16.5.2. Considerations for New Range Units . . . . . . . . . 181 339 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 181 340 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 181 341 16.6.2. Considerations for New Content Codings . . . . . . . 182 342 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 182 343 17. Security Considerations . . . . . . . . . . . . . . . . . . . 183 344 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 183 345 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 184 346 17.3. Attacks Based on File and Path Names . . . . . . . . . . 185 347 17.4. Attacks Based on Command, Code, or Query Injection . . . 185 348 17.5. Attacks via Protocol Element Length . . . . . . . . . . 186 349 17.6. Attacks using Shared-dictionary Compression . . . . . . 187 350 17.7. Disclosure of Personal Information . . . . . . . . . . . 187 351 17.8. Privacy of Server Log Information . . . . . . . . . . . 187 352 17.9. Disclosure of Sensitive Information in URIs . . . . . . 188 353 17.10. Application Handling of Field Names . . . . . . . . . . 188 354 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 189 355 17.12. Disclosure of Product Information . . . . . . . . . . . 190 356 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 190 357 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 191 358 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 191 359 17.16. Authentication Considerations . . . . . . . . . . . . . 192 360 17.16.1. Confidentiality of Credentials . . . . . . . . . . 192 361 17.16.2. Credentials and Idle Clients . . . . . . . . . . . 192 362 17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 193 363 17.16.4. Additional Response Fields . . . . . . . . . . . . 193 364 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 193 365 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 194 366 18.2. Method Registration . . . . . . . . . . . . . . . . . . 194 367 18.3. Status Code Registration . . . . . . . . . . . . . . . . 194 368 18.4. Field Name Registration . . . . . . . . . . . . . . . . 197 369 18.5. Authentication Scheme Registration . . . . . . . . . . . 199 370 18.6. Content Coding Registration . . . . . . . . . . . . . . 200 371 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 200 372 18.8. Media Type Registration . . . . . . . . . . . . . . . . 201 373 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 201 374 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 201 375 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 201 376 19.1. Normative References . . . . . . . . . . . . . . . . . . 201 377 19.2. Informative References . . . . . . . . . . . . . . . . . 203 378 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 210 379 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 214 380 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 214 381 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 214 382 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 215 383 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 217 384 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 218 385 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 218 386 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 218 387 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 218 388 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 218 389 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 218 390 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 218 391 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 219 392 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 219 393 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 221 394 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 222 395 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 222 396 C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 223 397 C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 224 398 C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 226 399 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 227 400 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 228 401 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 228 402 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 230 403 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 230 404 C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 232 405 C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 233 406 C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 235 407 C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 236 408 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 236 409 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 410 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248 412 1. Introduction 414 1.1. Purpose 416 The Hypertext Transfer Protocol (HTTP) is a family of stateless, 417 application-level, request/response protocols that share a generic 418 interface, extensible semantics, and self-descriptive messages to 419 enable flexible interaction with network-based hypertext information 420 systems. 422 HTTP hides the details of how a service is implemented by presenting 423 a uniform interface to clients that is independent of the types of 424 resources provided. Likewise, servers do not need to be aware of 425 each client's purpose: a request can be considered in isolation 426 rather than being associated with a specific type of client or a 427 predetermined sequence of application steps. This allows general- 428 purpose implementations to be used effectively in many different 429 contexts, reduces interaction complexity, and enables independent 430 evolution over time. 432 HTTP is also designed for use as an intermediation protocol, wherein 433 proxies and gateways can translate non-HTTP information systems into 434 a more generic interface. 436 One consequence of this flexibility is that the protocol cannot be 437 defined in terms of what occurs behind the interface. Instead, we 438 are limited to defining the syntax of communication, the intent of 439 received communication, and the expected behavior of recipients. If 440 the communication is considered in isolation, then successful actions 441 ought to be reflected in corresponding changes to the observable 442 interface provided by servers. However, since multiple clients might 443 act in parallel and perhaps at cross-purposes, we cannot require that 444 such changes be observable beyond the scope of a single response. 446 1.2. History and Evolution 448 HTTP has been the primary information transfer protocol for the World 449 Wide Web since its introduction in 1990. It began as a trivial 450 mechanism for low-latency requests, with a single method (GET) to 451 request transfer of a presumed hypertext document identified by a 452 given pathname. As the Web grew, HTTP was extended to enclose 453 requests and responses within messages, transfer arbitrary data 454 formats using MIME-like media types, and route requests through 455 intermediaries. These protocols were eventually defined as HTTP/0.9 456 and HTTP/1.0 (see [HTTP/1.0]). 458 HTTP/1.1 was designed to refine the protocol's features while 459 retaining compatibility with the existing text-based messaging 460 syntax, improving its interoperability, scalability, and robustness 461 across the Internet. This included length-based data delimiters for 462 both fixed and dynamic (chunked) content, a consistent framework for 463 content negotiation, opaque validators for conditional requests, 464 cache controls for better cache consistency, range requests for 465 partial updates, and default persistent connections. HTTP/1.1 was 466 introduced in 1995 and published on the standards track in 1997 467 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014 468 ([RFC7230] - [RFC7235]). 470 HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of 471 the existing TLS and TCP protocols for exchanging concurrent HTTP 472 messages with efficient field compression and server push. HTTP/3 473 ([HTTP/3]) provides greater independence for concurrent messages by 474 using QUIC as a secure multiplexed transport over UDP instead of TCP. 476 All three major versions of HTTP rely on the semantics defined by 477 this document. They have not obsoleted each other because each one 478 has specific benefits and limitations depending on the context of 479 use. Implementations are expected to choose the most appropriate 480 transport and messaging syntax for their particular context. 482 This revision of HTTP separates the definition of semantics (this 483 document) and caching ([CACHING]) from the current HTTP/1.1 messaging 484 syntax ([HTTP/1.1]) to allow each major protocol version to progress 485 independently while referring to the same core semantics. 487 1.3. Core Semantics 489 HTTP provides a uniform interface for interacting with a resource 490 (Section 3.1) - regardless of its type, nature, or implementation - 491 by sending messages that manipulate or transfer representations 492 (Section 3.2). 494 Each message is either a request or a response. A client constructs 495 request messages that communicate its intentions and routes those 496 messages toward an identified origin server. A server listens for 497 requests, parses each message received, interprets the message 498 semantics in relation to the identified target resource, and responds 499 to that request with one or more response messages. The client 500 examines received responses to see if its intentions were carried 501 out, determining what to do next based on the status codes and 502 content received. 504 HTTP semantics include the intentions defined by each request method 505 (Section 9), extensions to those semantics that might be described in 506 request header fields, status codes that describe the response 507 (Section 15), and other control data and resource metadata that might 508 be given in response fields. 510 Semantics also include representation metadata that describe how 511 content is intended to be interpreted by a recipient, request header 512 fields that might influence content selection, and the various 513 selection algorithms that are collectively referred to as _content 514 negotiation_ (Section 12). 516 1.4. Specifications Obsoleted by this Document 518 This document obsoletes the following specifications: 520 +============================================+===========+=========+ 521 | Title | Reference | Changes | 522 +============================================+===========+=========+ 523 | HTTP Over TLS | [RFC2818] | B.1 | 524 +--------------------------------------------+-----------+---------+ 525 | HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 | 526 +--------------------------------------------+-----------+---------+ 527 | HTTP/1.1 Semantics and Content | [RFC7231] | B.3 | 528 +--------------------------------------------+-----------+---------+ 529 | HTTP/1.1 Conditional Requests | [RFC7232] | B.4 | 530 +--------------------------------------------+-----------+---------+ 531 | HTTP/1.1 Range Requests | [RFC7233] | B.5 | 532 +--------------------------------------------+-----------+---------+ 533 | HTTP/1.1 Authentication | [RFC7235] | B.6 | 534 +--------------------------------------------+-----------+---------+ 535 | HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 | 536 +--------------------------------------------+-----------+---------+ 537 | HTTP Authentication-Info and Proxy- | [RFC7615] | B.8 | 538 | Authentication-Info Response Header Fields | | | 539 +--------------------------------------------+-----------+---------+ 540 | HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 | 541 +--------------------------------------------+-----------+---------+ 543 Table 1 545 [*] This document only obsoletes the portions of RFC 7230 that are 546 independent of the HTTP/1.1 messaging syntax and connection 547 management; the remaining bits of RFC 7230 are obsoleted by 548 "HTTP/1.1" [HTTP/1.1]. 550 2. Conformance 552 2.1. Syntax Notation 554 This specification uses the Augmented Backus-Naur Form (ABNF) 555 notation of [RFC5234], extended with the notation for case- 556 sensitivity in strings defined in [RFC7405]. 558 It also uses a list extension, defined in Section 5.6.1, that allows 559 for compact definition of comma-separated lists using a "#" operator 560 (similar to how the "*" operator indicates repetition). Appendix A 561 shows the collected grammar with all list operators expanded to 562 standard ABNF notation. 564 As a convention, ABNF rule names prefixed with "obs-" denote 565 "obsolete" grammar rules that appear for historical reasons. 567 The following core rules are included by reference, as defined in 568 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 569 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 570 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF 571 (line feed), OCTET (any 8-bit sequence of data), SP (space), and 572 VCHAR (any visible US-ASCII character). 574 Section 5.6 defines some generic syntactic components for field 575 values. 577 This specification uses the terms "character", "character encoding 578 scheme", "charset", and "protocol element" as they are defined in 579 [RFC6365]. 581 2.2. Requirements Notation 583 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 584 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 585 "OPTIONAL" in this document are to be interpreted as described in BCP 586 14 [RFC2119] [RFC8174] when, and only when, they appear in all 587 capitals, as shown here. 589 This specification targets conformance criteria according to the role 590 of a participant in HTTP communication. Hence, requirements are 591 placed on senders, recipients, clients, servers, user agents, 592 intermediaries, origin servers, proxies, gateways, or caches, 593 depending on what behavior is being constrained by the requirement. 594 Additional requirements are placed on implementations, resource 595 owners, and protocol element registrations when they apply beyond the 596 scope of a single communication. 598 The verb "generate" is used instead of "send" where a requirement 599 applies only to implementations that create the protocol element, 600 rather than an implementation that forwards a received element 601 downstream. 603 An implementation is considered conformant if it complies with all of 604 the requirements associated with the roles it partakes in HTTP. 606 A sender MUST NOT generate protocol elements that do not match the 607 grammar defined by the corresponding ABNF rules. Within a given 608 message, a sender MUST NOT generate protocol elements or syntax 609 alternatives that are only allowed to be generated by participants in 610 other roles (i.e., a role that the sender does not have for that 611 message). 613 Conformance to HTTP includes both conformance to the particular 614 messaging syntax of the protocol version in use and conformance to 615 the semantics of protocol elements sent. For example, a client that 616 claims conformance to HTTP/1.1 but fails to recognize the features 617 required of HTTP/1.1 recipients will fail to interoperate with 618 servers that adjust their responses in accordance with those claims. 619 Features that reflect user choices, such as content negotiation and 620 user-selected extensions, can impact application behavior beyond the 621 protocol stream; sending protocol elements that inaccurately reflect 622 a user's choices will confuse the user and inhibit choice. 624 When an implementation fails semantic conformance, recipients of that 625 implementation's messages will eventually develop workarounds to 626 adjust their behavior accordingly. A recipient MAY employ such 627 workarounds while remaining conformant to this protocol if the 628 workarounds are limited to the implementations at fault. For 629 example, servers often scan portions of the User-Agent field value, 630 and user agents often scan the Server field value, to adjust their 631 own behavior with respect to known bugs or poorly chosen defaults. 633 2.3. Length Requirements 635 A recipient SHOULD parse a received protocol element defensively, 636 with only marginal expectations that the element will conform to its 637 ABNF grammar and fit within a reasonable buffer size. 639 HTTP does not have specific length limitations for many of its 640 protocol elements because the lengths that might be appropriate will 641 vary widely, depending on the deployment context and purpose of the 642 implementation. Hence, interoperability between senders and 643 recipients depends on shared expectations regarding what is a 644 reasonable length for each protocol element. Furthermore, what is 645 commonly understood to be a reasonable length for some protocol 646 elements has changed over the course of the past two decades of HTTP 647 use and is expected to continue changing in the future. 649 At a minimum, a recipient MUST be able to parse and process protocol 650 element lengths that are at least as long as the values that it 651 generates for those same protocol elements in other messages. For 652 example, an origin server that publishes very long URI references to 653 its own resources needs to be able to parse and process those same 654 references when received as a target URI. 656 Many received protocol elements are only parsed to the extent 657 necessary to identify and forward that element downstream. For 658 example, an intermediary might parse a received field into its field 659 name and field value components, but then forward the field without 660 further parsing inside the field value. 662 2.4. Error Handling 664 A recipient MUST interpret a received protocol element according to 665 the semantics defined for it by this specification, including 666 extensions to this specification, unless the recipient has determined 667 (through experience or configuration) that the sender incorrectly 668 implements what is implied by those semantics. For example, an 669 origin server might disregard the contents of a received 670 Accept-Encoding header field if inspection of the User-Agent header 671 field indicates a specific implementation version that is known to 672 fail on receipt of certain content codings. 674 Unless noted otherwise, a recipient MAY attempt to recover a usable 675 protocol element from an invalid construct. HTTP does not define 676 specific error handling mechanisms except when they have a direct 677 impact on security, since different applications of the protocol 678 require different error handling strategies. For example, a Web 679 browser might wish to transparently recover from a response where the 680 Location header field doesn't parse according to the ABNF, whereas a 681 systems control client might consider any form of error recovery to 682 be dangerous. 684 Some requests can be automatically retried by a client in the event 685 of an underlying connection failure, as described in Section 9.2.2. 687 2.5. Protocol Version 689 HTTP's version number consists of two decimal digits separated by a 690 "." (period or decimal point). The first digit ("major version") 691 indicates the messaging syntax, whereas the second digit ("minor 692 version") indicates the highest minor version within that major 693 version to which the sender is conformant (able to understand for 694 future communication). 696 While HTTP's core semantics don't change between protocol versions, 697 the expression of them "on the wire" can change, and so the HTTP 698 version number changes when incompatible changes are made to the wire 699 format. Additionally, HTTP allows incremental, backwards-compatible 700 changes to be made to the protocol without changing its version 701 through the use of defined extension points (Section 16). 703 The protocol version as a whole indicates the sender's conformance 704 with the set of requirements laid out in that version's corresponding 705 specification of HTTP. For example, the version "HTTP/1.1" is 706 defined by the combined specifications of this document, "HTTP 707 Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1]. 709 HTTP's major version number is incremented when an incompatible 710 message syntax is introduced. The minor number is incremented when 711 changes made to the protocol have the effect of adding to the message 712 semantics or implying additional capabilities of the sender. 714 The minor version advertises the sender's communication capabilities 715 even when the sender is only using a backwards-compatible subset of 716 the protocol, thereby letting the recipient know that more advanced 717 features can be used in response (by servers) or in future requests 718 (by clients). 720 When a major version of HTTP does not define any minor versions, the 721 minor version "0" is implied. The "0" is used when referring to that 722 protocol within elements that require a minor version identifier. 724 3. Terminology and Core Concepts 726 HTTP was created for the World Wide Web (WWW) architecture and has 727 evolved over time to support the scalability needs of a worldwide 728 hypertext system. Much of that architecture is reflected in the 729 terminology used to define HTTP. 731 3.1. Resources 733 The target of an HTTP request is called a _resource_. HTTP does not 734 limit the nature of a resource; it merely defines an interface that 735 might be used to interact with resources. Most resources are 736 identified by a Uniform Resource Identifier (URI), as described in 737 Section 4. 739 One design goal of HTTP is to separate resource identification from 740 request semantics, which is made possible by vesting the request 741 semantics in the request method (Section 9) and a few request- 742 modifying header fields. A resource cannot treat a request in a 743 manner inconsistent with the semantics of the method of the request. 744 For example, though the URI of a resource might imply semantics that 745 are not safe, a client can expect the resource to avoid actions that 746 are unsafe when processing a request with a safe method (see 747 Section 9.2.1). 749 HTTP relies upon the Uniform Resource Identifier (URI) standard [URI] 750 to indicate the target resource (Section 7.1) and relationships 751 between resources. 753 3.2. Representations 755 A _representation_ is information that is intended to reflect a past, 756 current, or desired state of a given resource, in a format that can 757 be readily communicated via the protocol. A representation consists 758 of a set of representation metadata and a potentially unbounded 759 stream of representation data (Section 8). 761 HTTP allows "information hiding" behind its uniform interface by 762 defining communication with respect to a transferable representation 763 of the resource state, rather than transferring the resource itself. 764 This allows the resource identified by a URI to be anything, 765 including temporal functions like "the current weather in Laguna 766 Beach", while potentially providing information that represents that 767 resource at the time a message is generated [REST]. 769 The uniform interface is similar to a window through which one can 770 observe and act upon a thing only through the communication of 771 messages to an independent actor on the other side. A shared 772 abstraction is needed to represent ("take the place of") the current 773 or desired state of that thing in our communications. When a 774 representation is hypertext, it can provide both a representation of 775 the resource state and processing instructions that help guide the 776 recipient's future interactions. 778 A target resource might be provided with, or be capable of 779 generating, multiple representations that are each intended to 780 reflect the resource's current state. An algorithm, usually based on 781 content negotiation (Section 12), would be used to select one of 782 those representations as being most applicable to a given request. 783 This _selected representation_ provides the data and metadata for 784 evaluating conditional requests (Section 13) and constructing the 785 content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) 786 responses to GET (Section 9.3.1). 788 3.3. Connections, Clients and Servers 790 HTTP is a client/server protocol that operates over a reliable 791 transport- or session-layer _connection_. 793 An HTTP _client_ is a program that establishes a connection to a 794 server for the purpose of sending one or more HTTP requests. An HTTP 795 _server_ is a program that accepts connections in order to service 796 HTTP requests by sending HTTP responses. 798 The terms "client" and "server" refer only to the roles that these 799 programs perform for a particular connection. The same program might 800 act as a client on some connections and a server on others. 802 HTTP is defined as a stateless protocol, meaning that each request 803 message's semantics can be understood in isolation, and that the 804 relationship between connections and messages on them has no impact 805 on the interpretation of those messages. For example, a CONNECT 806 request (Section 9.3.6) or a request with the Upgrade header field 807 (Section 7.8) can occur at any time, not just in the first message on 808 a connection. Many implementations depend on HTTP's stateless design 809 in order to reuse proxied connections or dynamically load balance 810 requests across multiple servers. 812 As a result, a server MUST NOT assume that two requests on the same 813 connection are from the same user agent unless the connection is 814 secured and specific to that agent. Some non-standard HTTP 815 extensions (e.g., [RFC4559]) have been known to violate this 816 requirement, resulting in security and interoperability problems. 818 3.4. Messages 820 HTTP is a stateless request/response protocol for exchanging 821 _messages_ across a connection. The terms _sender_ and _recipient_ 822 refer to any implementation that sends or receives a given message, 823 respectively. 825 A client sends requests to a server in the form of a _request_ 826 message with a method (Section 9) and request target (Section 7.1). 827 The request might also contain header fields (Section 6.3) for 828 request modifiers, client information, and representation metadata, 829 content (Section 6.4) intended for processing in accordance with the 830 method, and trailer fields (Section 6.5) to communicate information 831 collected while sending the content. 833 A server responds to a client's request by sending one or more 834 _response_ messages, each including a status code (Section 15). The 835 response might also contain header fields for server information, 836 resource metadata, and representation metadata, content to be 837 interpreted in accordance with the status code, and trailer fields to 838 communicate information collected while sending the content. 840 3.5. User Agents 842 The term _user agent_ refers to any of the various client programs 843 that initiate a request. 845 The most familiar form of user agent is the general-purpose Web 846 browser, but that's only a small percentage of implementations. 847 Other common user agents include spiders (web-traversing robots), 848 command-line tools, billboard screens, household appliances, scales, 849 light bulbs, firmware update scripts, mobile apps, and communication 850 devices in a multitude of shapes and sizes. 852 Being a user agent does not imply that there is a human user directly 853 interacting with the software agent at the time of a request. In 854 many cases, a user agent is installed or configured to run in the 855 background and save its results for later inspection (or save only a 856 subset of those results that might be interesting or erroneous). 857 Spiders, for example, are typically given a start URI and configured 858 to follow certain behavior while crawling the Web as a hypertext 859 graph. 861 Many user agents cannot, or choose not to, make interactive 862 suggestions to their user or provide adequate warning for security or 863 privacy concerns. In the few cases where this specification requires 864 reporting of errors to the user, it is acceptable for such reporting 865 to only be observable in an error console or log file. Likewise, 866 requirements that an automated action be confirmed by the user before 867 proceeding might be met via advance configuration choices, run-time 868 options, or simple avoidance of the unsafe action; confirmation does 869 not imply any specific user interface or interruption of normal 870 processing if the user has already made that choice. 872 3.6. Origin Server 874 The term _origin server_ refers to a program that can originate 875 authoritative responses for a given target resource. 877 The most familiar form of origin server are large public websites. 878 However, like user agents being equated with browsers, it is easy to 879 be misled into thinking that all origin servers are alike. Common 880 origin servers also include home automation units, configurable 881 networking components, office machines, autonomous robots, news 882 feeds, traffic cameras, real-time ad selectors, and video-on-demand 883 platforms. 885 Most HTTP communication consists of a retrieval request (GET) for a 886 representation of some resource identified by a URI. In the simplest 887 case, this might be accomplished via a single bidirectional 888 connection (===) between the user agent (UA) and the origin server 889 (O). 891 request > 892 UA ======================================= O 893 < response 895 Figure 1 897 3.7. Intermediaries 899 HTTP enables the use of intermediaries to satisfy requests through a 900 chain of connections. There are three common forms of HTTP 901 _intermediary_: proxy, gateway, and tunnel. In some cases, a single 902 intermediary might act as an origin server, proxy, gateway, or 903 tunnel, switching behavior based on the nature of each request. 905 > > > > 906 UA =========== A =========== B =========== C =========== O 907 < < < < 909 Figure 2 911 The figure above shows three intermediaries (A, B, and C) between the 912 user agent and origin server. A request or response message that 913 travels the whole chain will pass through four separate connections. 914 Some HTTP communication options might apply only to the connection 915 with the nearest, non-tunnel neighbor, only to the endpoints of the 916 chain, or to all connections along the chain. Although the diagram 917 is linear, each participant might be engaged in multiple, 918 simultaneous communications. For example, B might be receiving 919 requests from many clients other than A, and/or forwarding requests 920 to servers other than C, at the same time that it is handling A's 921 request. Likewise, later requests might be sent through a different 922 path of connections, often based on dynamic configuration for load 923 balancing. 925 The terms _upstream_ and _downstream_ are used to describe 926 directional requirements in relation to the message flow: all 927 messages flow from upstream to downstream. The terms "inbound" and 928 "outbound" are used to describe directional requirements in relation 929 to the request route: _inbound_ means toward the origin server and 930 _outbound_ means toward the user agent. 932 A _proxy_ is a message-forwarding agent that is chosen by the client, 933 usually via local configuration rules, to receive requests for some 934 type(s) of absolute URI and attempt to satisfy those requests via 935 translation through the HTTP interface. Some translations are 936 minimal, such as for proxy requests for "http" URIs, whereas other 937 requests might require translation to and from entirely different 938 application-level protocols. Proxies are often used to group an 939 organization's HTTP requests through a common intermediary for the 940 sake of security, annotation services, or shared caching. Some 941 proxies are designed to apply transformations to selected messages or 942 content while they are being forwarded, as described in Section 7.7. 944 A _gateway_ (a.k.a. _reverse proxy_) is an intermediary that acts as 945 an origin server for the outbound connection but translates received 946 requests and forwards them inbound to another server or servers. 947 Gateways are often used to encapsulate legacy or untrusted 948 information services, to improve server performance through 949 _accelerator_ caching, and to enable partitioning or load balancing 950 of HTTP services across multiple machines. 952 All HTTP requirements applicable to an origin server also apply to 953 the outbound communication of a gateway. A gateway communicates with 954 inbound servers using any protocol that it desires, including private 955 extensions to HTTP that are outside the scope of this specification. 956 However, an HTTP-to-HTTP gateway that wishes to interoperate with 957 third-party HTTP servers needs to conform to user agent requirements 958 on the gateway's inbound connection. 960 A _tunnel_ acts as a blind relay between two connections without 961 changing the messages. Once active, a tunnel is not considered a 962 party to the HTTP communication, though the tunnel might have been 963 initiated by an HTTP request. A tunnel ceases to exist when both 964 ends of the relayed connection are closed. Tunnels are used to 965 extend a virtual connection through an intermediary, such as when 966 Transport Layer Security (TLS, [TLS13]) is used to establish 967 confidential communication through a shared firewall proxy. 969 The above categories for intermediary only consider those acting as 970 participants in the HTTP communication. There are also 971 intermediaries that can act on lower layers of the network protocol 972 stack, filtering or redirecting HTTP traffic without the knowledge or 973 permission of message senders. Network intermediaries are 974 indistinguishable (at a protocol level) from an on-path attacker, 975 often introducing security flaws or interoperability problems due to 976 mistakenly violating HTTP semantics. 978 For example, an _interception proxy_ [RFC3040] (also commonly known 979 as a _transparent proxy_ [RFC1919]) differs from an HTTP proxy 980 because it is not chosen by the client. Instead, an interception 981 proxy filters or redirects outgoing TCP port 80 packets (and 982 occasionally other common port traffic). Interception proxies are 983 commonly found on public network access points, as a means of 984 enforcing account subscription prior to allowing use of non-local 985 Internet services, and within corporate firewalls to enforce network 986 usage policies. 988 3.8. Caches 990 A _cache_ is a local store of previous response messages and the 991 subsystem that controls its message storage, retrieval, and deletion. 992 A cache stores cacheable responses in order to reduce the response 993 time and network bandwidth consumption on future, equivalent 994 requests. Any client or server MAY employ a cache, though a cache 995 cannot be used while acting as a tunnel. 997 The effect of a cache is that the request/response chain is shortened 998 if one of the participants along the chain has a cached response 999 applicable to that request. The following illustrates the resulting 1000 chain if B has a cached copy of an earlier response from O (via C) 1001 for a request that has not been cached by UA or A. 1003 > > 1004 UA =========== A =========== B - - - - - - C - - - - - - O 1005 < < 1007 Figure 3 1009 A response is _cacheable_ if a cache is allowed to store a copy of 1010 the response message for use in answering subsequent requests. Even 1011 when a response is cacheable, there might be additional constraints 1012 placed by the client or by the origin server on when that cached 1013 response can be used for a particular request. HTTP requirements for 1014 cache behavior and cacheable responses are defined in [CACHING]. 1016 There is a wide variety of architectures and configurations of caches 1017 deployed across the World Wide Web and inside large organizations. 1018 These include national hierarchies of proxy caches to save bandwidth 1019 and reduce latency, Content Delivery Networks that use gateway 1020 caching to optimise regional and global distribution of popular 1021 sites, collaborative systems that broadcast or multicast cache 1022 entries, archives of pre-fetched cache entries for use in off-line or 1023 high-latency environments, and so on. 1025 3.9. Example Message Exchange 1027 The following example illustrates a typical HTTP/1.1 message exchange 1028 for a GET request (Section 9.3.1) on the URI "http://www.example.com/ 1029 hello.txt": 1031 Client request: 1033 GET /hello.txt HTTP/1.1 1034 User-Agent: curl/7.64.1 1035 Host: www.example.com 1036 Accept-Language: en, mi 1038 Server response: 1040 HTTP/1.1 200 OK 1041 Date: Mon, 27 Jul 2009 12:28:53 GMT 1042 Server: Apache 1043 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 1044 ETag: "34aa387-d-1568eb00" 1045 Accept-Ranges: bytes 1046 Content-Length: 51 1047 Vary: Accept-Encoding 1048 Content-Type: text/plain 1050 Hello World! My content includes a trailing CRLF. 1052 4. Identifiers in HTTP 1054 Uniform Resource Identifiers (URIs) [URI] are used throughout HTTP as 1055 the means for identifying resources (Section 3.1). 1057 4.1. URI References 1059 URI references are used to target requests, indicate redirects, and 1060 define relationships. 1062 The definitions of "URI-reference", "absolute-URI", "relative-part", 1063 "authority", "port", "host", "path-abempty", "segment", and "query" 1064 are adopted from the URI generic syntax. An "absolute-path" rule is 1065 defined for protocol elements that can contain a non-empty path 1066 component. (This rule differs slightly from the path-abempty rule of 1067 RFC 3986, which allows for an empty path, and path-absolute rule, 1068 which does not allow paths that begin with "//".) A "partial-URI" 1069 rule is defined for protocol elements that can contain a relative URI 1070 but not a fragment component. 1072 URI-reference = 1073 absolute-URI = 1074 relative-part = 1075 authority = 1076 uri-host = 1077 port = 1078 path-abempty = 1079 segment = 1080 query = 1082 absolute-path = 1*( "/" segment ) 1083 partial-URI = relative-part [ "?" query ] 1085 Each protocol element in HTTP that allows a URI reference will 1086 indicate in its ABNF production whether the element allows any form 1087 of reference (URI-reference), only a URI in absolute form (absolute- 1088 URI), only the path and optional query components (partial-URI), or 1089 some combination of the above. Unless otherwise indicated, URI 1090 references are parsed relative to the target URI (Section 7.1). 1092 It is RECOMMENDED that all senders and recipients support, at a 1093 minimum, URIs with lengths of 8000 octets in protocol elements. Note 1094 that this implies some structures and on-wire representations (for 1095 example, the request line in HTTP/1.1) will necessarily be larger in 1096 some cases. 1098 4.2. HTTP-Related URI Schemes 1100 IANA maintains the registry of URI Schemes [BCP35] at 1101 . Although requests 1102 might target any URI scheme, the following schemes are inherent to 1103 HTTP servers: 1105 +============+====================================+=======+ 1106 | URI Scheme | Description | Ref. | 1107 +============+====================================+=======+ 1108 | http | Hypertext Transfer Protocol | 4.2.1 | 1109 +------------+------------------------------------+-------+ 1110 | https | Hypertext Transfer Protocol Secure | 4.2.2 | 1111 +------------+------------------------------------+-------+ 1113 Table 2 1115 Note that the presence of an "http" or "https" URI does not imply 1116 that there is always an HTTP server at the identified origin 1117 listening for connections. Anyone can mint a URI, whether or not a 1118 server exists and whether or not that server currently maps that 1119 identifier to a resource. The delegated nature of registered names 1120 and IP addresses creates a federated namespace whether or not an HTTP 1121 server is present. 1123 4.2.1. http URI Scheme 1125 The "http" URI scheme is hereby defined for minting identifiers 1126 within the hierarchical namespace governed by a potential HTTP origin 1127 server listening for TCP ([TCP]) connections on a given port. 1129 http-URI = "http" "://" authority path-abempty [ "?" query ] 1131 The origin server for an "http" URI is identified by the authority 1132 component, which includes a host identifier ([URI], Section 3.2.2) 1133 and optional port number ([URI], Section 3.2.3). If the port 1134 subcomponent is empty or not given, TCP port 80 (the reserved port 1135 for WWW services) is the default. The origin determines who has the 1136 right to respond authoritatively to requests that target the 1137 identified resource, as defined in Section 4.3.2. 1139 A sender MUST NOT generate an "http" URI with an empty host 1140 identifier. A recipient that processes such a URI reference MUST 1141 reject it as invalid. 1143 The hierarchical path component and optional query component identify 1144 the target resource within that origin server's name space. 1146 4.2.2. https URI Scheme 1148 The "https" URI scheme is hereby defined for minting identifiers 1149 within the hierarchical namespace governed by a potential origin 1150 server listening for TCP connections on a given port and capable of 1151 establishing a TLS ([TLS13]) connection that has been secured for 1152 HTTP communication. In this context, _secured_ specifically means 1153 that the server has been authenticated as acting on behalf of the 1154 identified authority and all HTTP communication with that server has 1155 confidentiality and integrity protection that is acceptable to both 1156 client and server. 1158 https-URI = "https" "://" authority path-abempty [ "?" query ] 1160 The origin server for an "https" URI is identified by the authority 1161 component, which includes a host identifier ([URI], Section 3.2.2) 1162 and optional port number ([URI], Section 3.2.3). If the port 1163 subcomponent is empty or not given, TCP port 443 (the reserved port 1164 for HTTP over TLS) is the default. The origin determines who has the 1165 right to respond authoritatively to requests that target the 1166 identified resource, as defined in Section 4.3.3. 1168 A sender MUST NOT generate an "https" URI with an empty host 1169 identifier. A recipient that processes such a URI reference MUST 1170 reject it as invalid. 1172 The hierarchical path component and optional query component identify 1173 the target resource within that origin server's name space. 1175 A client MUST ensure that its HTTP requests for an "https" resource 1176 are secured, prior to being communicated, and that it only accepts 1177 secured responses to those requests. Note that the definition of 1178 what cryptographic mechanisms are acceptable to client and server are 1179 usually negotiated and can change over time. 1181 Resources made available via the "https" scheme have no shared 1182 identity with the "http" scheme. They are distinct origins with 1183 separate namespaces. However, extensions to HTTP that are defined as 1184 applying to all origins with the same host, such as the Cookie 1185 protocol [COOKIE], allow information set by one service to impact 1186 communication with other services within a matching group of host 1187 domains. Such extensions ought to be designed with great care to 1188 prevent information obtained from a secured connection being 1189 inadvertently exchanged within an unsecured context. 1191 4.2.3. http(s) Normalization and Comparison 1193 The "http" and "https" URI are normalized and compared according to 1194 the methods defined in Section 6 of [URI], using the defaults 1195 described above for each scheme. 1197 HTTP does not require use of a specific method for determining 1198 equivalence. For example, a cache key might be compared as a simple 1199 string, after syntax-based normalization, or after scheme-based 1200 normalization. 1202 Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and 1203 "https" URIs involves the following additional rules: 1205 * If the port is equal to the default port for a scheme, the normal 1206 form is to omit the port subcomponent. 1208 * When not being used as the target of an OPTIONS request, an empty 1209 path component is equivalent to an absolute path of "/", so the 1210 normal form is to provide a path of "/" instead. 1212 * The scheme and host are case-insensitive and normally provided in 1213 lowercase; all other components are compared in a case-sensitive 1214 manner. 1216 * Characters other than those in the "reserved" set are equivalent 1217 to their percent-encoded octets: the normal form is to not encode 1218 them (see Sections 2.1 and 2.2 of [URI]). 1220 For example, the following three URIs are equivalent: 1222 http://example.com:80/~smith/home.html 1223 http://EXAMPLE.com/%7Esmith/home.html 1224 http://EXAMPLE.com:/%7esmith/home.html 1226 Two HTTP URIs that are equivalent after normalization (using any 1227 method) can be assumed to identify the same resource, and any HTTP 1228 component MAY perform normalization. As a result, distinct resources 1229 SHOULD NOT be identified by HTTP URIs that are equivalent after 1230 normalization (using any method defined in Section 6.2 of [URI]). 1232 4.2.4. Deprecation of userinfo in http(s) URIs 1234 The URI generic syntax for authority also includes a userinfo 1235 subcomponent ([URI], Section 3.2.1) for including user authentication 1236 information in the URI. In that subcomponent, the use of the format 1237 "user:password" is deprecated. 1239 Some implementations make use of the userinfo component for internal 1240 configuration of authentication information, such as within command 1241 invocation options, configuration files, or bookmark lists, even 1242 though such usage might expose a user identifier or password. 1244 A sender MUST NOT generate the userinfo subcomponent (and its "@" 1245 delimiter) when an "http" or "https" URI reference is generated 1246 within a message as a target URI or field value. 1248 Before making use of an "http" or "https" URI reference received from 1249 an untrusted source, a recipient SHOULD parse for userinfo and treat 1250 its presence as an error; it is likely being used to obscure the 1251 authority for the sake of phishing attacks. 1253 4.2.5. http(s) References with Fragment Identifiers 1255 Fragment identifiers allow for indirect identification of a secondary 1256 resource, independent of the URI scheme, as defined in Section 3.5 of 1257 [URI]. Some protocol elements that refer to a URI allow inclusion of 1258 a fragment, while others do not. They are distinguished by use of 1259 the ABNF rule for elements where fragment is allowed; otherwise, a 1260 specific rule that excludes fragments is used. 1262 | *Note:* The fragment identifier component is not part of the 1263 | scheme definition for a URI scheme (see Section 4.3 of [URI]), 1264 | thus does not appear in the ABNF definitions for the "http" and 1265 | "https" URI schemes above. 1267 4.3. Authoritative Access 1269 Authoritative access refers to dereferencing a given identifier, for 1270 the sake of access to the identified resource, in a way that the 1271 client believes is authoritative (controlled by the resource owner). 1272 The process for determining whether access is granted is defined by 1273 the URI scheme and often uses data within the URI components, such as 1274 the authority component when the generic syntax is used. However, 1275 authoritative access is not limited to the identified mechanism. 1277 Section 4.3.1 defines the concept of an origin as an aid to such 1278 uses, and the subsequent subsections explain how to establish that a 1279 peer has the authority to represent an origin. 1281 See Section 17.1 for security considerations related to establishing 1282 authority. 1284 4.3.1. URI Origin 1286 The _origin_ for a given URI is the triple of scheme, host, and port 1287 after normalizing the scheme and host to lowercase and normalizing 1288 the port to remove any leading zeros. If port is elided from the 1289 URI, the default port for that scheme is used. For example, the URI 1291 https://Example.Com/happy.js 1293 would have the origin 1295 { "https", "example.com", "443" } 1297 which can also be described as the normalized URI prefix with port 1298 always present: 1300 https://example.com:443 1302 Each origin defines its own namespace and controls how identifiers 1303 within that namespace are mapped to resources. In turn, how the 1304 origin responds to valid requests, consistently over time, determines 1305 the semantics that users will associate with a URI, and the 1306 usefulness of those semantics is what ultimately transforms these 1307 mechanisms into a "resource" for users to reference and access in the 1308 future. 1310 Two origins are distinct if they differ in scheme, host, or port. 1311 Even when it can be verified that the same entity controls two 1312 distinct origins, the two namespaces under those origins are distinct 1313 unless explicitly aliased by a server authoritative for that origin. 1315 Origin is also used within HTML and related Web protocols, beyond the 1316 scope of this document, as described in [RFC6454]. 1318 4.3.2. http origins 1320 Although HTTP is independent of the transport protocol, the "http" 1321 scheme (Section 4.2.1) is specific to associating authority with 1322 whomever controls the origin server listening for TCP connections on 1323 the indicated port of whatever host is identified within the 1324 authority component. This is a very weak sense of authority because 1325 it depends on both client-specific name resolution mechanisms and 1326 communication that might not be secured from an on-path attacker. 1327 Nevertheless, it is a sufficient minimum for binding "http" 1328 identifiers to an origin server for consistent resolution within a 1329 trusted environment. 1331 If the host identifier is provided as an IP address, the origin 1332 server is the listener (if any) on the indicated TCP port at that IP 1333 address. If host is a registered name, the registered name is an 1334 indirect identifier for use with a name resolution service, such as 1335 DNS, to find an address for an appropriate origin server. 1337 When an "http" URI is used within a context that calls for access to 1338 the indicated resource, a client MAY attempt access by resolving the 1339 host identifier to an IP address, establishing a TCP connection to 1340 that address on the indicated port, and sending an HTTP request 1341 message to the server containing the URI's identifying data. 1343 If the server responds to such a request with a non-interim HTTP 1344 response message, as described in Section 15, then that response is 1345 considered an authoritative answer to the client's request. 1347 Note, however, that the above is not the only means for obtaining an 1348 authoritative response, nor does it imply that an authoritative 1349 response is always necessary (see [CACHING]). For example, the Alt- 1350 Svc header field [ALTSVC] allows an origin server to identify other 1351 services that are also authoritative for that origin. Access to 1352 "http" identified resources might also be provided by protocols 1353 outside the scope of this document. 1355 4.3.3. https origins 1357 The "https" scheme (Section 4.2.2) associates authority based on the 1358 ability of a server to use the private key corresponding to a 1359 certificate that the client considers to be trustworthy for the 1360 identified origin server. The client usually relies upon a chain of 1361 trust, conveyed from some prearranged or configured trust anchor, to 1362 deem a certificate trustworthy (Section 4.3.4). 1364 In HTTP/1.1 and earlier, a client will only attribute authority to a 1365 server when they are communicating over a successfully established 1366 and secured connection specifically to that URI origin's host. The 1367 connection establishment and certificate verification are used as 1368 proof of authority. 1370 In HTTP/2 and HTTP/3, a client will attribute authority to a server 1371 when they are communicating over a successfully established and 1372 secured connection if the URI origin's host matches any of the hosts 1373 present in the server's certificate and the client believes that it 1374 could open a connection to that host for that URI. In practice, a 1375 client will make a DNS query to check that the origin's host contains 1376 the same server IP address as the established connection. This 1377 restriction can be removed by the origin server sending an equivalent 1378 ORIGIN frame [RFC8336]. 1380 The request target's host and port value are passed within each HTTP 1381 request, identifying the origin and distinguishing it from other 1382 namespaces that might be controlled by the same server (Section 7.2). 1383 It is the origin's responsibility to ensure that any services 1384 provided with control over its certificate's private key are equally 1385 responsible for managing the corresponding "https" namespaces, or at 1386 least prepared to reject requests that appear to have been 1387 misdirected (Section 7.4). 1389 An origin server might be unwilling to process requests for certain 1390 target URIs even when they have the authority to do so. For example, 1391 when a host operates distinct services on different ports (e.g., 443 1392 and 8000), checking the target URI at the origin server is necessary 1393 (even after the connection has been secured) because a network 1394 attacker might cause connections for one port to be received at some 1395 other port. Failing to check the target URI might allow such an 1396 attacker to replace a response to one target URI (e.g., 1397 "https://example.com/foo") with a seemingly authoritative response 1398 from the other port (e.g., "https://example.com:8000/foo"). 1400 Note that the "https" scheme does not rely on TCP and the connected 1401 port number for associating authority, since both are outside the 1402 secured communication and thus cannot be trusted as definitive. 1403 Hence, the HTTP communication might take place over any channel that 1404 has been secured, as defined in Section 4.2.2, including protocols 1405 that don't use TCP. 1407 When an "https" URI is used within a context that calls for access to 1408 the indicated resource, a client MAY attempt access by resolving the 1409 host identifier to an IP address, establishing a TCP connection to 1410 that address on the indicated port, securing the connection end-to- 1411 end by successfully initiating TLS over TCP with confidentiality and 1412 integrity protection, and sending an HTTP request message over that 1413 connection containing the URI's identifying data. 1415 If the server responds to such a request with a non-interim HTTP 1416 response message, as described in Section 15, then that response is 1417 considered an authoritative answer to the client's request. 1419 Note, however, that the above is not the only means for obtaining an 1420 authoritative response, nor does it imply that an authoritative 1421 response is always necessary (see [CACHING]). 1423 4.3.4. https certificate verification 1425 To establish a secured connection to dereference a URI, a client MUST 1426 verify that the service's identity is an acceptable match for the 1427 URI's origin server. Certificate verification is used to prevent 1428 server impersonation by an on-path attacker or by an attacker that 1429 controls name resolution. This process requires that a client be 1430 configured with a set of trust anchors. 1432 In general, a client MUST verify the service identity using the 1433 verification process defined in Section 6 of [RFC6125]. The client 1434 MUST construct a reference identity from the service's host: if the 1435 host is a literal IP address (Section 4.3.5), the reference identity 1436 is an IP-ID, otherwise the host is a name and the reference identity 1437 is a DNS-ID. 1439 A reference identity of type CN-ID MUST NOT be used by clients. As 1440 noted in Section 6.2.1 of [RFC6125] a reference identity of type CN- 1441 ID might be used by older clients. 1443 A client might be specially configured to accept an alternative form 1444 of server identity verification. For example, a client might be 1445 connecting to a server whose address and hostname are dynamic, with 1446 an expectation that the service will present a specific certificate 1447 (or a certificate matching some externally defined reference 1448 identity) rather than one matching the target URI's origin. 1450 In special cases, it might be appropriate for a client to simply 1451 ignore the server's identity, but it must be understood that this 1452 leaves a connection open to active attack. 1454 If the certificate is not valid for the target URI's origin, a user 1455 agent MUST either obtain confirmation from the user before proceeding 1456 (see Section 3.5) or terminate the connection with a bad certificate 1457 error. Automated clients MUST log the error to an appropriate audit 1458 log (if available) and SHOULD terminate the connection (with a bad 1459 certificate error). Automated clients MAY provide a configuration 1460 setting that disables this check, but MUST provide a setting which 1461 enables it. 1463 4.3.5. IP-ID reference identity 1465 A server that is identified using an IP address literal in the "host" 1466 field of an "https" URI has a reference identity of type IP-ID. An 1467 IP version 4 address uses the "IPv4address" ABNF rule and an IP 1468 version 6 address uses the "IP-literal" production with the 1469 "IPv6address" option; see Section 3.2.2 of [URI]. A reference 1470 identity of IP-ID contains the decoded bytes of the IP address. 1472 An IP version 4 address is 4 octets and an IP version 6 address is 16 1473 octets. Use of IP-ID is not defined for any other IP version. The 1474 iPAddress choice in the certificate subjectAltName extension does not 1475 explicitly include the IP version and so relies on the length of the 1476 address to distinguish versions; see Section 4.2.1.6 of [RFC5280]. 1478 A reference identity of type IP-ID matches if the address is 1479 identical to an iPAddress value of the subjectAltName extension of 1480 the certificate. 1482 5. Fields 1484 HTTP uses _fields_ to provide data in the form of extensible key/ 1485 value pairs with a registered key namespace. Fields are sent and 1486 received within the header and trailer sections of messages 1487 (Section 6). 1489 5.1. Field Names 1491 A field name labels the corresponding field value as having the 1492 semantics defined by that name. For example, the Date header field 1493 is defined in Section 10.2.2 as containing the origination timestamp 1494 for the message in which it appears. 1496 field-name = token 1498 Field names are case-insensitive and ought to be registered within 1499 the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see 1500 Section 16.3.1. 1502 The interpretation of a field does not change between minor versions 1503 of the same major HTTP version, though the default behavior of a 1504 recipient in the absence of such a field can change. Unless 1505 specified otherwise, fields are defined for all versions of HTTP. In 1506 particular, the Host and Connection fields ought to be recognized by 1507 all HTTP implementations whether or not they advertise conformance 1508 with HTTP/1.1. 1510 New fields can be introduced without changing the protocol version if 1511 their defined semantics allow them to be safely ignored by recipients 1512 that do not recognize them; see Section 16.3. 1514 A proxy MUST forward unrecognized header fields unless the field name 1515 is listed in the Connection header field (Section 7.6.1) or the proxy 1516 is specifically configured to block, or otherwise transform, such 1517 fields. Other recipients SHOULD ignore unrecognized header and 1518 trailer fields. Adhering to these requirements allows HTTP's 1519 functionality to be extended without updating or removing deployed 1520 intermediaries. 1522 5.2. Field Lines and Combined Field Value 1524 Field sections are composed of any number of _field lines_, each with 1525 a _field name_ (see Section 5.1) identifying the field, and a _field 1526 line value_ that conveys data for that instance of the field. 1528 When a field name is only present once in a section, the combined 1529 _field value_ for that field consists of the corresponding field line 1530 value. When a field name is repeated within a section, its combined 1531 field value consists of the list of corresponding field line values 1532 within that section, concatenated in order, with each field line 1533 value separated by a comma. 1535 For example, this section: 1537 Example-Field: Foo, Bar 1538 Example-Field: Baz 1540 contains two field lines, both with the field name "Example-Field". 1541 The first field line has a field line value of "Foo, Bar", while the 1542 second field line value is "Baz". The field value for "Example- 1543 Field" is the list "Foo, Bar, Baz". 1545 5.3. Field Order 1547 A recipient MAY combine multiple field lines within a field section 1548 that have the same field name into one field line, without changing 1549 the semantics of the message, by appending each subsequent field line 1550 value to the initial field line value in order, separated by a comma 1551 (",") and optional whitespace (OWS, defined in Section 5.6.3). For 1552 consistency, use comma SP. 1554 The order in which field lines with the same name are received is 1555 therefore significant to the interpretation of the field value; a 1556 proxy MUST NOT change the order of these field line values when 1557 forwarding a message. 1559 This means that, aside from the well-known exception noted below, a 1560 sender MUST NOT generate multiple field lines with the same name in a 1561 message (whether in the headers or trailers), or append a field line 1562 when a field line of the same name already exists in the message, 1563 unless that field's definition allows multiple field line values to 1564 be recombined as a comma-separated list [i.e., at least one 1565 alternative of the field's definition allows a comma-separated list, 1566 such as an ABNF rule of #(values) defined in Section 5.6.1]. 1568 | *Note:* In practice, the "Set-Cookie" header field ([COOKIE]) 1569 | often appears in a response message across multiple field lines 1570 | and does not use the list syntax, violating the above 1571 | requirements on multiple field lines with the same field name. 1572 | Since it cannot be combined into a single field value, 1573 | recipients ought to handle "Set-Cookie" as a special case while 1574 | processing fields. (See Appendix A.2.3 of [Kri2001] for 1575 | details.) 1577 The order in which field lines with differing field names are 1578 received in a section is not significant. However, it is good 1579 practice to send header fields that contain additional control data 1580 first, such as Host on requests and Date on responses, so that 1581 implementations can decide when not to handle a message as early as 1582 possible. 1584 A server MUST NOT apply a request to the target resource until it 1585 receives the entire request header section, since later header field 1586 lines might include conditionals, authentication credentials, or 1587 deliberately misleading duplicate header fields that could impact 1588 request processing. 1590 5.4. Field Limits 1592 HTTP does not place a predefined limit on the length of each field 1593 line, field value, or on the length of a header or trailer section as 1594 a whole, as described in Section 2. Various ad hoc limitations on 1595 individual lengths are found in practice, often depending on the 1596 specific field's semantics. 1598 A server that receives a request header field line, field value, or 1599 set of fields larger than it wishes to process MUST respond with an 1600 appropriate 4xx (Client Error) status code. Ignoring such header 1601 fields would increase the server's vulnerability to request smuggling 1602 attacks (Section 11.2 of [HTTP/1.1]). 1604 A client MAY discard or truncate received field lines that are larger 1605 than the client wishes to process if the field semantics are such 1606 that the dropped value(s) can be safely ignored without changing the 1607 message framing or response semantics. 1609 5.5. Field Values 1611 HTTP field values consist of a sequence of characters in a format 1612 defined by the field's grammar. Each field's grammar is usually 1613 defined using ABNF ([RFC5234]). 1615 field-value = *field-content 1616 field-content = field-vchar 1617 [ 1*( SP / HTAB / field-vchar ) field-vchar ] 1618 field-vchar = VCHAR / obs-text 1620 A field value does not include leading or trailing whitespace. When 1621 a specific version of HTTP allows such whitespace to appear in a 1622 message, a field parsing implementation MUST exclude such whitespace 1623 prior to evaluating the field value. 1625 Field values are usually constrained to the range of US-ASCII 1626 characters [USASCII]. Fields needing a greater range of characters 1627 can use an encoding, such as the one defined in [RFC8187]. 1628 Historically, HTTP allowed field content with text in the ISO-8859-1 1629 charset [ISO-8859-1], supporting other charsets only through use of 1630 [RFC2047] encoding. Specifications for newly defined fields SHOULD 1631 limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. 1632 A recipient SHOULD treat other octets in field content (obs-text) as 1633 opaque data. 1635 Field values containing CR or NUL characters are invalid and 1636 dangerous, due to the varying ways that implementations might parse 1637 and interpret those characters; a recipient of CR or NUL within a 1638 field value MUST either reject the message or replace each of those 1639 characters with SP before further processing or forwarding of that 1640 message. Field values containing other CTL characters are also 1641 invalid; however, recipients MAY retain such characters for the sake 1642 of robustness if they only appear within safe field value contexts 1643 (e.g., opaque data). 1645 Fields that only anticipate a single member as the field value are 1646 referred to as _singleton fields_. 1648 Fields that allow multiple members as the field value are referred to 1649 as _list-based fields_. The list operator extension of Section 5.6.1 1650 is used as a common notation for defining field values that can 1651 contain multiple members. 1653 Because commas (",") are used as the delimiter between members, they 1654 need to be treated with care if they are allowed as data within a 1655 member. This is true for both list-based and singleton fields, since 1656 a singleton field might be erroneously sent with multiple members and 1657 detecting such errors improves interoperability. Fields that expect 1658 to contain a comma within a member, such as within an HTTP-date or 1659 URI-reference element, ought to be defined with delimiters around 1660 that element to distinguish any comma within that data from potential 1661 list separators. 1663 For example, a textual date and a URI (either of which might contain 1664 a comma) could be safely carried in list-based field values like 1665 these: 1667 Example-URIs: "http://example.com/a.html,foo", 1668 "http://without-a-comma.example.com/" 1669 Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 1671 Note that double-quote delimiters are almost always used with the 1672 quoted-string production (Section 5.6.4); using a different syntax 1673 inside double-quotes will likely cause unnecessary confusion. 1675 Many fields (such as Content-Type, defined in Section 8.3) use a 1676 common syntax for parameters that allows both unquoted (token) and 1677 quoted (quoted-string) syntax for a parameter value (Section 5.6.6). 1678 Use of common syntax allows recipients to reuse existing parser 1679 components. When allowing both forms, the meaning of a parameter 1680 value ought to be the same whether it was received as a token or a 1681 quoted string. 1683 Historically, HTTP field values could be extended over multiple lines 1684 by preceding each extra line with at least one space or horizontal 1685 tab (obs-fold). This document assumes that any such obsolete line 1686 folding has been removed prior to interpreting the field value (e.g., 1687 as described in Section 5.2 of [HTTP/1.1]). 1689 | *Note:* For defining field value syntax, this specification 1690 | uses an ABNF rule named after the field name to define the 1691 | allowed grammar for that field's value (after said value has 1692 | been extracted from the underlying messaging syntax and 1693 | multiple instances combined into a list). 1695 5.6. Common Rules for Defining Field Values 1697 5.6.1. Lists (#rule ABNF Extension) 1699 A #rule extension to the ABNF rules of [RFC5234] is used to improve 1700 readability in the definitions of some list-based field values. 1702 A construct "#" is defined, similar to "*", for defining comma- 1703 delimited lists of elements. The full form is "#element" 1704 indicating at least and at most elements, each separated by a 1705 single comma (",") and optional whitespace (OWS, defined in 1706 Section 5.6.3). 1708 5.6.1.1. Sender Requirements 1710 In any production that uses the list construct, a sender MUST NOT 1711 generate empty list elements. In other words, a sender MUST generate 1712 lists that satisfy the following syntax: 1714 1#element => element *( OWS "," OWS element ) 1716 and: 1718 #element => [ 1#element ] 1720 and for n >= 1 and m > 1: 1722 #element => element *( OWS "," OWS element ) 1724 Appendix A shows the collected ABNF for senders after the list 1725 constructs have been expanded. 1727 5.6.1.2. Recipient Requirements 1729 Empty elements do not contribute to the count of elements present. A 1730 recipient MUST parse and ignore a reasonable number of empty list 1731 elements: enough to handle common mistakes by senders that merge 1732 values, but not so much that they could be used as a denial-of- 1733 service mechanism. In other words, a recipient MUST accept lists 1734 that satisfy the following syntax: 1736 #element => [ element ] *( OWS "," OWS [ element ] ) 1738 Note that because of the potential presence of empty list elements, 1739 the RFC 5234 ABNF cannot enforce the cardinality of list elements, 1740 and consequently all cases are mapped as if there was no cardinality 1741 specified. 1743 For example, given these ABNF productions: 1745 example-list = 1#example-list-elmt 1746 example-list-elmt = token ; see Section 5.6.2 1748 Then the following are valid values for example-list (not including 1749 the double quotes, which are present for delimitation only): 1751 "foo,bar" 1752 "foo ,bar," 1753 "foo , ,bar,charlie" 1755 In contrast, the following values would be invalid, since at least 1756 one non-empty element is required by the example-list production: 1758 "" 1759 "," 1760 ", ," 1762 5.6.2. Tokens 1764 Tokens are short textual identifiers that do not include whitespace 1765 or delimiters. 1767 token = 1*tchar 1769 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1770 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1771 / DIGIT / ALPHA 1772 ; any VCHAR, except delimiters 1774 Many HTTP field values are defined using common syntax components, 1775 separated by whitespace or specific delimiting characters. 1776 Delimiters are chosen from the set of US-ASCII visual characters not 1777 allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}"). 1779 5.6.3. Whitespace 1781 This specification uses three rules to denote the use of linear 1782 whitespace: OWS (optional whitespace), RWS (required whitespace), and 1783 BWS ("bad" whitespace). 1785 The OWS rule is used where zero or more linear whitespace octets 1786 might appear. For protocol elements where optional whitespace is 1787 preferred to improve readability, a sender SHOULD generate the 1788 optional whitespace as a single SP; otherwise, a sender SHOULD NOT 1789 generate optional whitespace except as needed to overwrite invalid or 1790 unwanted protocol elements during in-place message filtering. 1792 The RWS rule is used when at least one linear whitespace octet is 1793 required to separate field tokens. A sender SHOULD generate RWS as a 1794 single SP. 1796 OWS and RWS have the same semantics as a single SP. Any content 1797 known to be defined as OWS or RWS MAY be replaced with a single SP 1798 before interpreting it or forwarding the message downstream. 1800 The BWS rule is used where the grammar allows optional whitespace 1801 only for historical reasons. A sender MUST NOT generate BWS in 1802 messages. A recipient MUST parse for such bad whitespace and remove 1803 it before interpreting the protocol element. 1805 BWS has no semantics. Any content known to be defined as BWS MAY be 1806 removed before interpreting it or forwarding the message downstream. 1808 OWS = *( SP / HTAB ) 1809 ; optional whitespace 1810 RWS = 1*( SP / HTAB ) 1811 ; required whitespace 1812 BWS = OWS 1813 ; "bad" whitespace 1815 5.6.4. Quoted Strings 1817 A string of text is parsed as a single value if it is quoted using 1818 double-quote marks. 1820 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 1821 qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text 1822 obs-text = %x80-FF 1824 The backslash octet ("\") can be used as a single-octet quoting 1825 mechanism within quoted-string and comment constructs. Recipients 1826 that process the value of a quoted-string MUST handle a quoted-pair 1827 as if it were replaced by the octet following the backslash. 1829 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 1831 A sender SHOULD NOT generate a quoted-pair in a quoted-string except 1832 where necessary to quote DQUOTE and backslash octets occurring within 1833 that string. A sender SHOULD NOT generate a quoted-pair in a comment 1834 except where necessary to quote parentheses ["(" and ")"] and 1835 backslash octets occurring within that comment. 1837 5.6.5. Comments 1839 Comments can be included in some HTTP fields by surrounding the 1840 comment text with parentheses. Comments are only allowed in fields 1841 containing "comment" as part of their field value definition. 1843 comment = "(" *( ctext / quoted-pair / comment ) ")" 1844 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1846 5.6.6. Parameters 1848 Parameters are instances of name=value pairs; they are often used in 1849 field values as a common syntax for appending auxiliary information 1850 to an item. Each parameter is usually delimited by an immediately 1851 preceding semicolon. 1853 parameters = *( OWS ";" OWS [ parameter ] ) 1854 parameter = parameter-name "=" parameter-value 1855 parameter-name = token 1856 parameter-value = ( token / quoted-string ) 1858 Parameter names are case-insensitive. Parameter values might or 1859 might not be case-sensitive, depending on the semantics of the 1860 parameter name. Examples of parameters and some equivalent forms can 1861 be seen in media types (Section 8.3.1) and the Accept header field 1862 (Section 12.5.1). 1864 A parameter value that matches the token production can be 1865 transmitted either as a token or within a quoted-string. The quoted 1866 and unquoted values are equivalent. 1868 | *Note:* Parameters do not allow whitespace (not even "bad" 1869 | whitespace) around the "=" character. 1871 5.6.7. Date/Time Formats 1873 Prior to 1995, there were three different formats commonly used by 1874 servers to communicate timestamps. For compatibility with old 1875 implementations, all three are defined here. The preferred format is 1876 a fixed-length and single-zone subset of the date and time 1877 specification used by the Internet Message Format [RFC5322]. 1879 HTTP-date = IMF-fixdate / obs-date 1881 An example of the preferred format is 1883 Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate 1885 Examples of the two obsolete formats are 1887 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1888 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1890 A recipient that parses a timestamp value in an HTTP field MUST 1891 accept all three HTTP-date formats. When a sender generates a field 1892 that contains one or more timestamps defined as HTTP-date, the sender 1893 MUST generate those timestamps in the IMF-fixdate format. 1895 An HTTP-date value represents time as an instance of Coordinated 1896 Universal Time (UTC). The first two formats indicate UTC by the 1897 three-letter abbreviation for Greenwich Mean Time, "GMT", a 1898 predecessor of the UTC name; values in the asctime format are assumed 1899 to be in UTC. A sender that generates HTTP-date values from a local 1900 clock ought to use NTP ([RFC5905]) or some similar protocol to 1901 synchronize its clock to UTC. 1903 Preferred format: 1905 IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT 1906 ; fixed length/zone/capitalization subset of the format 1907 ; see Section 3.3 of [RFC5322] 1909 day-name = %s"Mon" / %s"Tue" / %s"Wed" 1910 / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun" 1912 date1 = day SP month SP year 1913 ; e.g., 02 Jun 1982 1915 day = 2DIGIT 1916 month = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr" 1917 / %s"May" / %s"Jun" / %s"Jul" / %s"Aug" 1918 / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec" 1919 year = 4DIGIT 1921 GMT = %s"GMT" 1923 time-of-day = hour ":" minute ":" second 1924 ; 00:00:00 - 23:59:60 (leap second) 1926 hour = 2DIGIT 1927 minute = 2DIGIT 1928 second = 2DIGIT 1930 Obsolete formats: 1932 obs-date = rfc850-date / asctime-date 1934 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1935 date2 = day "-" month "-" 2DIGIT 1936 ; e.g., 02-Jun-82 1938 day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday" 1939 / %s"Thursday" / %s"Friday" / %s"Saturday" 1940 / %s"Sunday" 1942 asctime-date = day-name SP date3 SP time-of-day SP year 1943 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1944 ; e.g., Jun 2 1946 HTTP-date is case sensitive. Note that Section 4.2 of [CACHING] 1947 relaxes this for cache recipients. 1949 A sender MUST NOT generate additional whitespace in an HTTP-date 1950 beyond that specifically included as SP in the grammar. The 1951 semantics of day-name, day, month, year, and time-of-day are the same 1952 as those defined for the Internet Message Format constructs with the 1953 corresponding name ([RFC5322], Section 3.3). 1955 Recipients of a timestamp value in rfc850-date format, which uses a 1956 two-digit year, MUST interpret a timestamp that appears to be more 1957 than 50 years in the future as representing the most recent year in 1958 the past that had the same last two digits. 1960 Recipients of timestamp values are encouraged to be robust in parsing 1961 timestamps unless otherwise restricted by the field definition. For 1962 example, messages are occasionally forwarded over HTTP from a non- 1963 HTTP source that might generate any of the date and time 1964 specifications defined by the Internet Message Format. 1966 | *Note:* HTTP requirements for the date/time stamp format apply 1967 | only to their usage within the protocol stream. 1968 | Implementations are not required to use these formats for user 1969 | presentation, request logging, etc. 1971 6. Message Abstraction 1973 Each major version of HTTP defines its own syntax for communicating 1974 messages. This section defines an abstract data type for HTTP 1975 messages based on a generalization of those message characteristics, 1976 common structure, and capacity for conveying semantics. This 1977 abstraction is used to define requirements on senders and recipients 1978 that are independent of the HTTP version, such that a message in one 1979 version can be relayed through other versions without changing its 1980 meaning. 1982 A _message_ consists of control data to describe and route the 1983 message, a headers lookup table of key/value pairs for extending that 1984 control data and conveying additional information about the sender, 1985 message, content, or context, a potentially unbounded stream of 1986 content, and a trailers lookup table of key/value pairs for 1987 communicating information obtained while sending the content. 1989 Framing and control data is sent first, followed by a header section 1990 containing fields for the headers table. When a message includes 1991 content, the content is sent after the header section, potentially 1992 followed by a trailer section that might contain fields for the 1993 trailers table. 1995 Messages are expected to be processed as a stream, wherein the 1996 purpose of that stream and its continued processing is revealed while 1997 being read. Hence, control data describes what the recipient needs 1998 to know immediately, header fields describe what needs to be known 1999 before receiving content, the content (when present) presumably 2000 contains what the recipient wants or needs to fulfill the message 2001 semantics, and trailer fields provide optional metadata that was 2002 unknown prior to sending the content. 2004 Messages are intended to be _self-descriptive_: everything a 2005 recipient needs to know about the message can be determined by 2006 looking at the message itself, after decoding or reconstituting parts 2007 that have been compressed or elided in transit, without requiring an 2008 understanding of the sender's current application state (established 2009 via prior messages). However, a client MUST retain knowledge of the 2010 request when parsing, interpreting, or caching a corresponding 2011 response. For example, responses to the HEAD method look just like 2012 the beginning of a response to GET, but cannot be parsed in the same 2013 manner. 2015 Note that this message abstraction is a generalization across many 2016 versions of HTTP, including features that might not be found in some 2017 versions. For example, trailers were introduced within the HTTP/1.1 2018 chunked transfer coding as a trailer section after the content. An 2019 equivalent feature is present in HTTP/2 and HTTP/3 within the header 2020 block that terminates each stream. 2022 6.1. Framing and Completeness 2024 Message framing indicates how each message begins and ends, such that 2025 each message can be distinguished from other messages or noise on the 2026 same connection. Each major version of HTTP defines its own framing 2027 mechanism. 2029 HTTP/0.9 and early deployments of HTTP/1.0 used closure of the 2030 underlying connection to end a response. For backwards 2031 compatibility, this implicit framing is also allowed in HTTP/1.1. 2032 However, implicit framing can fail to distinguish an incomplete 2033 response if the connection closes early. For that reason, almost all 2034 modern implementations use explicit framing in the form of length- 2035 delimited sequences of message data. 2037 A message is considered _complete_ when all of the octets indicated 2038 by its framing are available. Note that, when no explicit framing is 2039 used, a response message that is ended by the underlying connection's 2040 close is considered complete even though it might be 2041 indistinguishable from an incomplete response, unless a transport- 2042 level error indicates that it is not complete. 2044 6.2. Control Data 2046 Messages start with control data that describe its primary purpose. 2047 Request message control data includes a request method (Section 9), 2048 request target (Section 7.1), and protocol version (Section 2.5). 2049 Response message control data includes a status code (Section 15), 2050 optional reason phrase, and protocol version. 2052 In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the 2053 first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]), 2054 control data is sent as pseudo-header fields with a reserved name 2055 prefix (e.g., ":authority"). 2057 Every HTTP message has a protocol version. Depending on the version 2058 in use, it might be identified within the message explicitly or 2059 inferred by the connection over which the message is received. 2060 Recipients use that version information to determine limitations or 2061 potential for later communication with that sender. 2063 When a message is forwarded by an intermediary, the protocol version 2064 is updated to reflect the version used by that intermediary. The Via 2065 header field (Section 7.6.3) is used to communicate upstream protocol 2066 information within a forwarded message. 2068 A client SHOULD send a request version equal to the highest version 2069 to which the client is conformant and whose major version is no 2070 higher than the highest version supported by the server, if this is 2071 known. A client MUST NOT send a version to which it is not 2072 conformant. 2074 A client MAY send a lower request version if it is known that the 2075 server incorrectly implements the HTTP specification, but only after 2076 the client has attempted at least one normal request and determined 2077 from the response status code or header fields (e.g., Server) that 2078 the server improperly handles higher request versions. 2080 A server SHOULD send a response version equal to the highest version 2081 to which the server is conformant that has a major version less than 2082 or equal to the one received in the request. A server MUST NOT send 2083 a version to which it is not conformant. A server can send a 505 2084 (HTTP Version Not Supported) response if it wishes, for any reason, 2085 to refuse service of the client's major protocol version. 2087 A recipient that receives a message with a major version number that 2088 it implements and a minor version number higher than what it 2089 implements SHOULD process the message as if it were in the highest 2090 minor version within that major version to which the recipient is 2091 conformant. A recipient can assume that a message with a higher 2092 minor version, when sent to a recipient that has not yet indicated 2093 support for that higher version, is sufficiently backwards-compatible 2094 to be safely processed by any implementation of the same major 2095 version. 2097 6.3. Header Fields 2099 Fields (Section 5) that are sent/received before the content are 2100 referred to as "header fields" (or just "headers", colloquially). 2102 The _header section_ of a message consists of a sequence of header 2103 field lines. Each header field might modify or extend message 2104 semantics, describe the sender, define the content, or provide 2105 additional context. 2107 | *Note:* We refer to named fields specifically as a "header 2108 | field" when they are only allowed to be sent in the header 2109 | section. 2111 6.4. Content 2113 HTTP messages often transfer a complete or partial representation as 2114 the message _content_: a stream of octets sent after the header 2115 section, as delineated by the message framing. 2117 This abstract definition of content reflects the data after it has 2118 been extracted from the message framing. For example, an HTTP/1.1 2119 message body (Section 6 of [HTTP/1.1]) might consist of a stream of 2120 data encoded with the chunked transfer coding - a sequence of data 2121 chunks, one zero-length chunk, and a trailer section - whereas the 2122 content of that same message includes only the data stream after the 2123 transfer coding has been decoded; it does not include the chunk 2124 lengths, chunked framing syntax, nor the trailer fields 2125 (Section 6.5). 2127 | *Note:* Some field names have a "Content-" prefix. This is an 2128 | informal convention; while some of these fields refer to the 2129 | content of the message, as defined above, others are scoped to 2130 | the selected representation (Section 3.2). See the individual 2131 | field's definition to disambiguate. 2133 6.4.1. Content Semantics 2135 The purpose of content in a request is defined by the method 2136 semantics (Section 9). 2138 For example, a representation in the content of a PUT request 2139 (Section 9.3.4) represents the desired state of the target resource 2140 after the request is successfully applied, whereas a representation 2141 in the content of a POST request (Section 9.3.3) represents 2142 information to be processed by the target resource. 2144 In a response, the content's purpose is defined by both the request 2145 method and the response status code (Section 15). For example, the 2146 content of a 200 (OK) response to GET (Section 9.3.1) represents the 2147 current state of the target resource, as observed at the time of the 2148 message origination date (Section 10.2.2), whereas the content of the 2149 same status code in a response to POST might represent either the 2150 processing result or the new state of the target resource after 2151 applying the processing. 2153 The content of a 206 (Partial Content) response to GET contains 2154 either a single part of the selected representation or a multipart 2155 message body containing multiple parts of that representation, as 2156 described in Section 15.3.7. 2158 Response messages with an error status code usually contain content 2159 that represents the error condition, such that the content describes 2160 the error state and what steps are suggested for resolving it. 2162 Responses to the HEAD request method (Section 9.3.2) never include 2163 content; the associated response header fields indicate only what 2164 their values would have been if the request method had been GET 2165 (Section 9.3.1). 2167 2xx (Successful) responses to a CONNECT request method 2168 (Section 9.3.6) switch the connection to tunnel mode instead of 2169 having content. 2171 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 2172 responses do not include content. 2174 All other responses do include content, although that content might 2175 be of zero length. 2177 6.4.2. Identifying Content 2179 When a complete or partial representation is transferred as message 2180 content, it is often desirable for the sender to supply, or the 2181 recipient to determine, an identifier for a resource corresponding to 2182 that specific representation. For example, a client making a GET 2183 request on a resource for "the current weather report" might want an 2184 identifier specific to the content returned (e.g., "weather report 2185 for Laguna Beach at 20210720T1711"). This can be useful for sharing 2186 or bookmarking content from resources that are expected to have 2187 changing representations over time. 2189 For a request message: 2191 * If the request has a Content-Location header field, then the 2192 sender asserts that the content is a representation of the 2193 resource identified by the Content-Location field value. However, 2194 such an assertion cannot be trusted unless it can be verified by 2195 other means (not defined by this specification). The information 2196 might still be useful for revision history links. 2198 * Otherwise, the content is unidentified by HTTP, but a more 2199 specific identifier might be supplied within the content itself. 2201 For a response message, the following rules are applied in order 2202 until a match is found: 2204 1. If the request method is HEAD or the response status code is 204 2205 (No Content) or 304 (Not Modified), there is no content in the 2206 response. 2208 2. If the request method is GET and the response status code is 200 2209 (OK), the content is a representation of the resource identified 2210 by the target URI (Section 7.1). 2212 3. If the request method is GET and the response status code is 203 2213 (Non-Authoritative Information), the content is a potentially 2214 modified or enhanced representation of the target resource as 2215 provided by an intermediary. 2217 4. If the request method is GET and the response status code is 206 2218 (Partial Content), the content is one or more parts of a 2219 representation of the resource identified by the target URI 2220 (Section 7.1). 2222 5. If the response has a Content-Location header field and its field 2223 value is a reference to the same URI as the target URI, the 2224 content is a representation of the target resource. 2226 6. If the response has a Content-Location header field and its field 2227 value is a reference to a URI different from the target URI, then 2228 the sender asserts that the content is a representation of the 2229 resource identified by the Content-Location field value. 2230 However, such an assertion cannot be trusted unless it can be 2231 verified by other means (not defined by this specification). 2233 7. Otherwise, the content is unidentified by HTTP, but a more 2234 specific identifier might be supplied within the content itself. 2236 6.5. Trailer Fields 2238 Fields (Section 5) that are located within a _trailer section_ are 2239 referred to as "trailer fields" (or just "trailers", colloquially). 2240 Trailer fields can be useful for supplying message integrity checks, 2241 digital signatures, delivery metrics, or post-processing status 2242 information. 2244 Trailer fields ought to be processed and stored separately from the 2245 fields in the header section to avoid contradicting message semantics 2246 known at the time the header section was complete. The presence or 2247 absence of certain header fields might impact choices made for the 2248 routing or processing of the message as a whole before the trailers 2249 are received; those choices cannot be unmade by the later discovery 2250 of trailer fields. 2252 6.5.1. Limitations on use of Trailers 2254 A trailer section is only possible when supported by the version of 2255 HTTP in use and enabled by an explicit framing mechanism. For 2256 example, the chunked coding in HTTP/1.1 allows a trailer section to 2257 be sent after the content (Section 7.1.2 of [HTTP/1.1]). 2259 Many fields cannot be processed outside the header section because 2260 their evaluation is necessary prior to receiving the content, such as 2261 those that describe message framing, routing, authentication, request 2262 modifiers, response controls, or content format. A sender MUST NOT 2263 generate a trailer field unless the sender knows the corresponding 2264 header field name's definition permits the field to be sent in 2265 trailers. 2267 Trailer fields can be difficult to process by intermediaries that 2268 forward messages from one protocol version to another. If the entire 2269 message can be buffered in transit, some intermediaries could merge 2270 trailer fields into the header section (as appropriate) before it is 2271 forwarded. However, in most cases, the trailers are simply 2272 discarded. A recipient MUST NOT merge a trailer field into a header 2273 section unless the recipient understands the corresponding header 2274 field definition and that definition explicitly permits and defines 2275 how trailer field values can be safely merged. 2277 The presence of the keyword "trailers" in the TE header field 2278 (Section 10.1.4) of a request indicates that the client is willing to 2279 accept trailer fields, on behalf of itself and any downstream 2280 clients. For requests from an intermediary, this implies that all 2281 downstream clients are willing to accept trailer fields in the 2282 forwarded response. Note that the presence of "trailers" does not 2283 mean that the client(s) will process any particular trailer field in 2284 the response; only that the trailer section(s) will not be dropped by 2285 any of the clients. 2287 Because of the potential for trailer fields to be discarded in 2288 transit, a server SHOULD NOT generate trailer fields that it believes 2289 are necessary for the user agent to receive. 2291 6.5.2. Processing Trailer Fields 2293 The "Trailer" header field (Section 10.1.5) can be sent to indicate 2294 fields likely to be sent in the trailer section, which allows 2295 recipients to prepare for their receipt before processing the 2296 content. For example, this could be useful if a field name indicates 2297 that a dynamic checksum should be calculated as the content is 2298 received and then immediately checked upon receipt of the trailer 2299 field value. 2301 Like header fields, trailer fields with the same name are processed 2302 in the order received; multiple trailer field lines with the same 2303 name have the equivalent semantics as appending the multiple values 2304 as a list of members. Trailer fields that might be generated more 2305 than once during a message MUST be defined as a list-based field even 2306 if each member value is only processed once per field line received. 2308 At the end of a message, a recipient MAY treat the set of received 2309 trailer fields as a data structure of key/value pairs, similar to 2310 (but separate from) the header fields. Additional processing 2311 expectations, if any, can be defined within the field specification 2312 for a field intended for use in trailers. 2314 7. Routing HTTP Messages 2316 HTTP request message routing is determined by each client based on 2317 the target resource, the client's proxy configuration, and 2318 establishment or reuse of an inbound connection. The corresponding 2319 response routing follows the same connection chain back to the 2320 client. 2322 7.1. Determining the Target Resource 2324 Although HTTP is used in a wide variety of applications, most clients 2325 rely on the same resource identification mechanism and configuration 2326 techniques as general-purpose Web browsers. Even when communication 2327 options are hard-coded in a client's configuration, we can think of 2328 their combined effect as a URI reference (Section 4.1). 2330 A URI reference is resolved to its absolute form in order to obtain 2331 the _target URI_. The target URI excludes the reference's fragment 2332 component, if any, since fragment identifiers are reserved for 2333 client-side processing ([URI], Section 3.5). 2335 To perform an action on a _target resource_, the client sends a 2336 request message containing enough components of its parsed target URI 2337 to enable recipients to identify that same resource. For historical 2338 reasons, the parsed target URI components, collectively referred to 2339 as the _request target_, are sent within the message control data and 2340 the Host header field (Section 7.2). 2342 There are two unusual cases for which the request target components 2343 are in a method-specific form: 2345 * For CONNECT (Section 9.3.6), the request target is the host name 2346 and port number of the tunnel destination, separated by a colon. 2348 * For OPTIONS (Section 9.3.7), the request target can be a single 2349 asterisk ("*"). 2351 See the respective method definitions for details. These forms MUST 2352 NOT be used with other methods. 2354 Upon receipt of a client's request, a server reconstructs the target 2355 URI from the received components in accordance with their local 2356 configuration and incoming connection context. This reconstruction 2357 is specific to each major protocol version. For example, Section 3.3 2358 of [HTTP/1.1] defines how a server determines the target URI of an 2359 HTTP/1.1 request. 2361 | *Note:* Previous specifications defined the recomposed target 2362 | URI as a distinct concept, the _effective request URI_. 2364 7.2. Host and :authority 2366 The "Host" header field in a request provides the host and port 2367 information from the target URI, enabling the origin server to 2368 distinguish among resources while servicing requests for multiple 2369 host names. 2371 In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in 2372 some cases, supplanted by the ":authority" pseudo-header field of a 2373 request's control data. 2375 Host = uri-host [ ":" port ] ; Section 4 2377 The target URI's authority information is critical for handling a 2378 request. A user agent MUST generate a Host header field in a request 2379 unless it sends that information as an ":authority" pseudo-header 2380 field. A user agent that sends Host SHOULD send it as the first 2381 field in the header section of a request. 2383 For example, a GET request to the origin server for 2384 would begin with: 2386 GET /pub/WWW/ HTTP/1.1 2387 Host: www.example.org 2389 Since the host and port information acts as an application-level 2390 routing mechanism, it is a frequent target for malware seeking to 2391 poison a shared cache or redirect a request to an unintended server. 2392 An interception proxy is particularly vulnerable if it relies on the 2393 host and port information for redirecting requests to internal 2394 servers, or for use as a cache key in a shared cache, without first 2395 verifying that the intercepted connection is targeting a valid IP 2396 address for that host. 2398 7.3. Routing Inbound Requests 2400 Once the target URI and its origin are determined, a client decides 2401 whether a network request is necessary to accomplish the desired 2402 semantics and, if so, where that request is to be directed. 2404 7.3.1. To a Cache 2406 If the client has a cache [CACHING] and the request can be satisfied 2407 by it, then the request is usually directed there first. 2409 7.3.2. To a Proxy 2411 If the request is not satisfied by a cache, then a typical client 2412 will check its configuration to determine whether a proxy is to be 2413 used to satisfy the request. Proxy configuration is implementation- 2414 dependent, but is often based on URI prefix matching, selective 2415 authority matching, or both, and the proxy itself is usually 2416 identified by an "http" or "https" URI. If a proxy is applicable, 2417 the client connects inbound by establishing (or reusing) a connection 2418 to that proxy. 2420 7.3.3. To the Origin 2422 If no proxy is applicable, a typical client will invoke a handler 2423 routine, usually specific to the target URI's scheme, to connect 2424 directly to an origin for the target resource. How that is 2425 accomplished is dependent on the target URI scheme and defined by its 2426 associated specification. 2428 7.4. Rejecting Misdirected Requests 2430 Once a request is received by a server and parsed sufficiently to 2431 determine its target URI, the server decides whether to process the 2432 request itself, forward the request to another server, redirect the 2433 client to a different resource, respond with an error, or drop the 2434 connection. This decision can be influenced by anything about the 2435 request or connection context, but is specifically directed at 2436 whether the server has been configured to process requests for that 2437 target URI and whether the connection context is appropriate for that 2438 request. 2440 For example, a request might have been misdirected, deliberately or 2441 accidentally, such that the information within a received Host header 2442 field differs from the connection's host or port. If the connection 2443 is from a trusted gateway, such inconsistency might be expected; 2444 otherwise, it might indicate an attempt to bypass security filters, 2445 trick the server into delivering non-public content, or poison a 2446 cache. See Section 17 for security considerations regarding message 2447 routing. 2449 Unless the connection is from a trusted gateway, an origin server 2450 MUST reject a request if any scheme-specific requirements for the 2451 target URI are not met. In particular, a request for an "https" 2452 resource MUST be rejected unless it has been received over a 2453 connection that has been secured via a certificate valid for that 2454 target URI's origin, as defined by Section 4.2.2. 2456 The 421 (Misdirected Request) status code in a response indicates 2457 that the origin server has rejected the request because it appears to 2458 have been misdirected (Section 15.5.20). 2460 7.5. Response Correlation 2462 A connection might be used for multiple request/response exchanges. 2463 The mechanism used to correlate between request and response messages 2464 is version dependent; some versions of HTTP use implicit ordering of 2465 messages, while others use an explicit identifier. 2467 All responses, regardless of the status code (including interim 2468 responses) can be sent at any time after a request is received, even 2469 if the request is not yet complete. A response can complete before 2470 its corresponding request is complete (Section 6.1). Likewise, 2471 clients are not expected to wait any specific amount of time for a 2472 response. Clients (including intermediaries) might abandon a request 2473 if the response is not forthcoming within a reasonable period of 2474 time. 2476 A client that receives a response while it is still sending the 2477 associated request SHOULD continue sending that request, unless it 2478 receives an explicit indication to the contrary (see, e.g., 2479 Section 9.5 of [HTTP/1.1] and Section 6.4 of [HTTP/2]). 2481 7.6. Message Forwarding 2483 As described in Section 3.7, intermediaries can serve a variety of 2484 roles in the processing of HTTP requests and responses. Some 2485 intermediaries are used to improve performance or availability. 2486 Others are used for access control or to filter content. Since an 2487 HTTP stream has characteristics similar to a pipe-and-filter 2488 architecture, there are no inherent limits to the extent an 2489 intermediary can enhance (or interfere) with either direction of the 2490 stream. 2492 Intermediaries are expected to forward messages even when protocol 2493 elements are not recognized (e.g., new methods, status codes, or 2494 field names), since that preserves extensibility for downstream 2495 recipients. 2497 An intermediary not acting as a tunnel MUST implement the Connection 2498 header field, as specified in Section 7.6.1, and exclude fields from 2499 being forwarded that are only intended for the incoming connection. 2501 An intermediary MUST NOT forward a message to itself unless it is 2502 protected from an infinite request loop. In general, an intermediary 2503 ought to recognize its own server names, including any aliases, local 2504 variations, or literal IP addresses, and respond to such requests 2505 directly. 2507 An HTTP message can be parsed as a stream for incremental processing 2508 or forwarding downstream. However, senders and recipients cannot 2509 rely on incremental delivery of partial messages, since some 2510 implementations will buffer or delay message forwarding for the sake 2511 of network efficiency, security checks, or content transformations. 2513 7.6.1. Connection 2515 The "Connection" header field allows the sender to list desired 2516 control options for the current connection. 2518 When a field aside from Connection is used to supply control 2519 information for or about the current connection, the sender MUST list 2520 the corresponding field name within the Connection header field. 2521 Note that some versions of HTTP prohibit the use of fields for such 2522 information, and therefore do not allow the Connection field. 2524 Intermediaries MUST parse a received Connection header field before a 2525 message is forwarded and, for each connection-option in this field, 2526 remove any header or trailer field(s) from the message with the same 2527 name as the connection-option, and then remove the Connection header 2528 field itself (or replace it with the intermediary's own connection 2529 options for the forwarded message). 2531 Hence, the Connection header field provides a declarative way of 2532 distinguishing fields that are only intended for the immediate 2533 recipient ("hop-by-hop") from those fields that are intended for all 2534 recipients on the chain ("end-to-end"), enabling the message to be 2535 self-descriptive and allowing future connection-specific extensions 2536 to be deployed without fear that they will be blindly forwarded by 2537 older intermediaries. 2539 Furthermore, intermediaries SHOULD remove or replace field(s) whose 2540 semantics are known to require removal before forwarding, whether or 2541 not they appear as a Connection option, after applying those fields' 2542 semantics. This includes but is not limited to: 2544 * Proxy-Connection (Appendix C.2.2 of [HTTP/1.1]) 2546 * Keep-Alive (Section 19.7.1 of [RFC2068]) 2548 * TE (Section 10.1.4) 2549 * Transfer-Encoding (Section 6.1 of [HTTP/1.1]) 2551 * Upgrade (Section 7.8) 2553 The Connection header field's value has the following grammar: 2555 Connection = #connection-option 2556 connection-option = token 2558 Connection options are case-insensitive. 2560 A sender MUST NOT send a connection option corresponding to a field 2561 that is intended for all recipients of the content. For example, 2562 Cache-Control is never appropriate as a connection option 2563 (Section 5.2 of [CACHING]). 2565 Connection options do not always correspond to a field present in the 2566 message, since a connection-specific field might not be needed if 2567 there are no parameters associated with a connection option. In 2568 contrast, a connection-specific field received without a 2569 corresponding connection option usually indicates that the field has 2570 been improperly forwarded by an intermediary and ought to be ignored 2571 by the recipient. 2573 When defining a new connection option that does not correspond to a 2574 field, specification authors ought to reserve the corresponding field 2575 name anyway in order to avoid later collisions. Such reserved field 2576 names are registered in the Hypertext Transfer Protocol (HTTP) Field 2577 Name Registry (Section 16.3.1). 2579 7.6.2. Max-Forwards 2581 The "Max-Forwards" header field provides a mechanism with the TRACE 2582 (Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit 2583 the number of times that the request is forwarded by proxies. This 2584 can be useful when the client is attempting to trace a request that 2585 appears to be failing or looping mid-chain. 2587 Max-Forwards = 1*DIGIT 2589 The Max-Forwards value is a decimal integer indicating the remaining 2590 number of times this request message can be forwarded. 2592 Each intermediary that receives a TRACE or OPTIONS request containing 2593 a Max-Forwards header field MUST check and update its value prior to 2594 forwarding the request. If the received value is zero (0), the 2595 intermediary MUST NOT forward the request; instead, the intermediary 2596 MUST respond as the final recipient. If the received Max-Forwards 2597 value is greater than zero, the intermediary MUST generate an updated 2598 Max-Forwards field in the forwarded message with a field value that 2599 is the lesser of a) the received value decremented by one (1) or b) 2600 the recipient's maximum supported value for Max-Forwards. 2602 A recipient MAY ignore a Max-Forwards header field received with any 2603 other request methods. 2605 7.6.3. Via 2607 The "Via" header field indicates the presence of intermediate 2608 protocols and recipients between the user agent and the server (on 2609 requests) or between the origin server and the client (on responses), 2610 similar to the "Received" header field in email (Section 3.6.7 of 2611 [RFC5322]). Via can be used for tracking message forwards, avoiding 2612 request loops, and identifying the protocol capabilities of senders 2613 along the request/response chain. 2615 Via = #( received-protocol RWS received-by [ RWS comment ] ) 2617 received-protocol = [ protocol-name "/" ] protocol-version 2618 ; see Section 7.8 2619 received-by = pseudonym [ ":" port ] 2620 pseudonym = token 2622 Each member of the Via field value represents a proxy or gateway that 2623 has forwarded the message. Each intermediary appends its own 2624 information about how the message was received, such that the end 2625 result is ordered according to the sequence of forwarding recipients. 2627 A proxy MUST send an appropriate Via header field, as described 2628 below, in each message that it forwards. An HTTP-to-HTTP gateway 2629 MUST send an appropriate Via header field in each inbound request 2630 message and MAY send a Via header field in forwarded response 2631 messages. 2633 For each intermediary, the received-protocol indicates the protocol 2634 and protocol version used by the upstream sender of the message. 2635 Hence, the Via field value records the advertised protocol 2636 capabilities of the request/response chain such that they remain 2637 visible to downstream recipients; this can be useful for determining 2638 what backwards-incompatible features might be safe to use in 2639 response, or within a later request, as described in Section 2.5. 2640 For brevity, the protocol-name is omitted when the received protocol 2641 is HTTP. 2643 The received-by portion is normally the host and optional port number 2644 of a recipient server or client that subsequently forwarded the 2645 message. However, if the real host is considered to be sensitive 2646 information, a sender MAY replace it with a pseudonym. If a port is 2647 not provided, a recipient MAY interpret that as meaning it was 2648 received on the default port, if any, for the received-protocol. 2650 A sender MAY generate comments to identify the software of each 2651 recipient, analogous to the User-Agent and Server header fields. 2652 However, comments in Via are optional, and a recipient MAY remove 2653 them prior to forwarding the message. 2655 For example, a request message could be sent from an HTTP/1.0 user 2656 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2657 forward the request to a public proxy at p.example.net, which 2658 completes the request by forwarding it to the origin server at 2659 www.example.com. The request received by www.example.com would then 2660 have the following Via header field: 2662 Via: 1.0 fred, 1.1 p.example.net 2664 An intermediary used as a portal through a network firewall SHOULD 2665 NOT forward the names and ports of hosts within the firewall region 2666 unless it is explicitly enabled to do so. If not enabled, such an 2667 intermediary SHOULD replace each received-by host of any host behind 2668 the firewall by an appropriate pseudonym for that host. 2670 An intermediary MAY combine an ordered subsequence of Via header 2671 field list members into a single member if the entries have identical 2672 received-protocol values. For example, 2674 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2676 could be collapsed to 2678 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2680 A sender SHOULD NOT combine multiple list members unless they are all 2681 under the same organizational control and the hosts have already been 2682 replaced by pseudonyms. A sender MUST NOT combine members that have 2683 different received-protocol values. 2685 7.7. Message Transformations 2687 Some intermediaries include features for transforming messages and 2688 their content. A proxy might, for example, convert between image 2689 formats in order to save cache space or to reduce the amount of 2690 traffic on a slow link. However, operational problems might occur 2691 when these transformations are applied to content intended for 2692 critical applications, such as medical imaging or scientific data 2693 analysis, particularly when integrity checks or digital signatures 2694 are used to ensure that the content received is identical to the 2695 original. 2697 An HTTP-to-HTTP proxy is called a _transforming proxy_ if it is 2698 designed or configured to modify messages in a semantically 2699 meaningful way (i.e., modifications, beyond those required by normal 2700 HTTP processing, that change the message in a way that would be 2701 significant to the original sender or potentially significant to 2702 downstream recipients). For example, a transforming proxy might be 2703 acting as a shared annotation server (modifying responses to include 2704 references to a local annotation database), a malware filter, a 2705 format transcoder, or a privacy filter. Such transformations are 2706 presumed to be desired by whichever client (or client organization) 2707 chose the proxy. 2709 If a proxy receives a target URI with a host name that is not a fully 2710 qualified domain name, it MAY add its own domain to the host name it 2711 received when forwarding the request. A proxy MUST NOT change the 2712 host name if the target URI contains a fully qualified domain name. 2714 A proxy MUST NOT modify the "absolute-path" and "query" parts of the 2715 received target URI when forwarding it to the next inbound server, 2716 except as noted above to replace an empty path with "/" or "*". 2718 A proxy MUST NOT transform the content (Section 6.4) of a message 2719 that contains a no-transform cache-control response directive 2720 (Section 5.2 of [CACHING]). Note that this does not include changes 2721 to the message body that do not affect the content, such as transfer 2722 codings (Section 7 of [HTTP/1.1]). 2724 A proxy MAY transform the content of a message that does not contain 2725 a no-transform cache-control directive. A proxy that transforms the 2726 content of a 200 (OK) response can inform downstream recipients that 2727 a transformation has been applied by changing the response status 2728 code to 203 (Non-Authoritative Information) (Section 15.3.4). 2730 A proxy SHOULD NOT modify header fields that provide information 2731 about the endpoints of the communication chain, the resource state, 2732 or the selected representation (other than the content) unless the 2733 field's definition specifically allows such modification or the 2734 modification is deemed necessary for privacy or security. 2736 7.8. Upgrade 2738 The "Upgrade" header field is intended to provide a simple mechanism 2739 for transitioning from HTTP/1.1 to some other protocol on the same 2740 connection. 2742 A client MAY send a list of protocol names in the Upgrade header 2743 field of a request to invite the server to switch to one or more of 2744 the named protocols, in order of descending preference, before 2745 sending the final response. A server MAY ignore a received Upgrade 2746 header field if it wishes to continue using the current protocol on 2747 that connection. Upgrade cannot be used to insist on a protocol 2748 change. 2750 Upgrade = #protocol 2752 protocol = protocol-name ["/" protocol-version] 2753 protocol-name = token 2754 protocol-version = token 2756 Although protocol names are registered with a preferred case, 2757 recipients SHOULD use case-insensitive comparison when matching each 2758 protocol-name to supported protocols. 2760 A server that sends a 101 (Switching Protocols) response MUST send an 2761 Upgrade header field to indicate the new protocol(s) to which the 2762 connection is being switched; if multiple protocol layers are being 2763 switched, the sender MUST list the protocols in layer-ascending 2764 order. A server MUST NOT switch to a protocol that was not indicated 2765 by the client in the corresponding request's Upgrade header field. A 2766 server MAY choose to ignore the order of preference indicated by the 2767 client and select the new protocol(s) based on other factors, such as 2768 the nature of the request or the current load on the server. 2770 A server that sends a 426 (Upgrade Required) response MUST send an 2771 Upgrade header field to indicate the acceptable protocols, in order 2772 of descending preference. 2774 A server MAY send an Upgrade header field in any other response to 2775 advertise that it implements support for upgrading to the listed 2776 protocols, in order of descending preference, when appropriate for a 2777 future request. 2779 The following is a hypothetical example sent by a client: 2781 GET /hello HTTP/1.1 2782 Host: www.example.com 2783 Connection: upgrade 2784 Upgrade: websocket, IRC/6.9, RTA/x11 2786 The capabilities and nature of the application-level communication 2787 after the protocol change is entirely dependent upon the new 2788 protocol(s) chosen. However, immediately after sending the 101 2789 (Switching Protocols) response, the server is expected to continue 2790 responding to the original request as if it had received its 2791 equivalent within the new protocol (i.e., the server still has an 2792 outstanding request to satisfy after the protocol has been changed, 2793 and is expected to do so without requiring the request to be 2794 repeated). 2796 For example, if the Upgrade header field is received in a GET request 2797 and the server decides to switch protocols, it first responds with a 2798 101 (Switching Protocols) message in HTTP/1.1 and then immediately 2799 follows that with the new protocol's equivalent of a response to a 2800 GET on the target resource. This allows a connection to be upgraded 2801 to protocols with the same semantics as HTTP without the latency cost 2802 of an additional round trip. A server MUST NOT switch protocols 2803 unless the received message semantics can be honored by the new 2804 protocol; an OPTIONS request can be honored by any protocol. 2806 The following is an example response to the above hypothetical 2807 request: 2809 HTTP/1.1 101 Switching Protocols 2810 Connection: upgrade 2811 Upgrade: websocket 2813 [... data stream switches to websocket with an appropriate response 2814 (as defined by new protocol) to the "GET /hello" request ...] 2816 A sender of Upgrade MUST also send an "Upgrade" connection option in 2817 the Connection header field (Section 7.6.1) to inform intermediaries 2818 not to forward this field. A server that receives an Upgrade header 2819 field in an HTTP/1.0 request MUST ignore that Upgrade field. 2821 A client cannot begin using an upgraded protocol on the connection 2822 until it has completely sent the request message (i.e., the client 2823 can't change the protocol it is sending in the middle of a message). 2824 If a server receives both an Upgrade and an Expect header field with 2825 the "100-continue" expectation (Section 10.1.1), the server MUST send 2826 a 100 (Continue) response before sending a 101 (Switching Protocols) 2827 response. 2829 The Upgrade header field only applies to switching protocols on top 2830 of the existing connection; it cannot be used to switch the 2831 underlying connection (transport) protocol, nor to switch the 2832 existing communication to a different connection. For those 2833 purposes, it is more appropriate to use a 3xx (Redirection) response 2834 (Section 15.4). 2836 This specification only defines the protocol name "HTTP" for use by 2837 the family of Hypertext Transfer Protocols, as defined by the HTTP 2838 version rules of Section 2.5 and future updates to this 2839 specification. Additional protocol names ought to be registered 2840 using the registration procedure defined in Section 16.7. 2842 8. Representation Data and Metadata 2844 8.1. Representation Data 2846 The representation data associated with an HTTP message is either 2847 provided as the content of the message or referred to by the message 2848 semantics and the target URI. The representation data is in a format 2849 and encoding defined by the representation metadata header fields. 2851 The data type of the representation data is determined via the header 2852 fields Content-Type and Content-Encoding. These define a two-layer, 2853 ordered encoding model: 2855 representation-data := Content-Encoding( Content-Type( data ) ) 2857 8.2. Representation Metadata 2859 Representation header fields provide metadata about the 2860 representation. When a message includes content, the representation 2861 header fields describe how to interpret that data. In a response to 2862 a HEAD request, the representation header fields describe the 2863 representation data that would have been enclosed in the content if 2864 the same request had been a GET. 2866 8.3. Content-Type 2868 The "Content-Type" header field indicates the media type of the 2869 associated representation: either the representation enclosed in the 2870 message content or the selected representation, as determined by the 2871 message semantics. The indicated media type defines both the data 2872 format and how that data is intended to be processed by a recipient, 2873 within the scope of the received message semantics, after any content 2874 codings indicated by Content-Encoding are decoded. 2876 Content-Type = media-type 2878 Media types are defined in Section 8.3.1. An example of the field is 2880 Content-Type: text/html; charset=ISO-8859-4 2882 A sender that generates a message containing content SHOULD generate 2883 a Content-Type header field in that message unless the intended media 2884 type of the enclosed representation is unknown to the sender. If a 2885 Content-Type header field is not present, the recipient MAY either 2886 assume a media type of "application/octet-stream" ([RFC2046], 2887 Section 4.5.1) or examine the data to determine its type. 2889 In practice, resource owners do not always properly configure their 2890 origin server to provide the correct Content-Type for a given 2891 representation. Some user agents examine the content and, in certain 2892 cases, override the received type (for example, see [Sniffing]). 2893 This "MIME sniffing" risks drawing incorrect conclusions about the 2894 data, which might expose the user to additional security risks (e.g., 2895 "privilege escalation"). Furthermore, it is impossible to determine 2896 the sender's intended processing model by examining the data format: 2897 many data formats match multiple media types that differ only in 2898 processing semantics. Implementers are encouraged to provide a means 2899 to disable such sniffing. 2901 Furthermore, although Content-Type is defined as a singleton field, 2902 it is sometimes incorrectly generated multiple times, resulting in a 2903 combined field value that appears to be a list. Recipients often 2904 attempt to handle this error by using the last syntactically valid 2905 member of the list, but note that some implementations might have 2906 different error handling behaviors, leading to interoperability and/ 2907 or security issues. 2909 8.3.1. Media Type 2911 HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and 2912 Accept (Section 12.5.1) header fields in order to provide open and 2913 extensible data typing and type negotiation. Media types define both 2914 a data format and various processing models: how to process that data 2915 in accordance with the message context. 2917 media-type = type "/" subtype parameters 2918 type = token 2919 subtype = token 2921 The type and subtype tokens are case-insensitive. 2923 The type/subtype MAY be followed by semicolon-delimited parameters 2924 (Section 5.6.6) in the form of name=value pairs. The presence or 2925 absence of a parameter might be significant to the processing of a 2926 media type, depending on its definition within the media type 2927 registry. Parameter values might or might not be case-sensitive, 2928 depending on the semantics of the parameter name. 2930 For example, the following media types are equivalent in describing 2931 HTML text data encoded in the UTF-8 character encoding scheme, but 2932 the first is preferred for consistency (the "charset" parameter value 2933 is defined as being case-insensitive in [RFC2046], Section 4.1.2): 2935 text/html;charset=utf-8 2936 Text/HTML;Charset="utf-8" 2937 text/html; charset="utf-8" 2938 text/html;charset=UTF-8 2940 Media types ought to be registered with IANA according to the 2941 procedures defined in [BCP13]. 2943 8.3.2. Charset 2945 HTTP uses _charset_ names to indicate or negotiate the character 2946 encoding scheme ([RFC6365], Section 1.3) of a textual representation. 2947 In the fields defined by this document, charset names appear either 2948 in parameters (Content-Type), or, for Accept-Encoding, in the form of 2949 a plain token. In both cases, charset names are matched case- 2950 insensitively. 2952 Charset names ought to be registered in the IANA "Character Sets" 2953 registry () 2954 according to the procedures defined in Section 2 of [RFC2978]. 2956 | *Note:* In theory, charset names are defined by the "mime- 2957 | charset" ABNF rule defined in Section 2.3 of [RFC2978] (as 2958 | corrected in [Err1912]). That rule allows two characters that 2959 | are not included in "token" ("{" and "}"), but no charset name 2960 | registered at the time of this writing includes braces (see 2961 | [Err5433]). 2963 8.3.3. Multipart Types 2965 MIME provides for a number of "multipart" types - encapsulations of 2966 one or more representations within a single message body. All 2967 multipart types share a common syntax, as defined in Section 5.1.1 of 2968 [RFC2046], and include a boundary parameter as part of the media type 2969 value. The message body is itself a protocol element; a sender MUST 2970 generate only CRLF to represent line breaks between body parts. 2972 HTTP message framing does not use the multipart boundary as an 2973 indicator of message body length, though it might be used by 2974 implementations that generate or process the content. For example, 2975 the "multipart/form-data" type is often used for carrying form data 2976 in a request, as described in [RFC7578], and the "multipart/ 2977 byteranges" type is defined by this specification for use in some 206 2978 (Partial Content) responses (see Section 15.3.7). 2980 8.4. Content-Encoding 2982 The "Content-Encoding" header field indicates what content codings 2983 have been applied to the representation, beyond those inherent in the 2984 media type, and thus what decoding mechanisms have to be applied in 2985 order to obtain data in the media type referenced by the Content-Type 2986 header field. Content-Encoding is primarily used to allow a 2987 representation's data to be compressed without losing the identity of 2988 its underlying media type. 2990 Content-Encoding = #content-coding 2992 An example of its use is 2994 Content-Encoding: gzip 2996 If one or more encodings have been applied to a representation, the 2997 sender that applied the encodings MUST generate a Content-Encoding 2998 header field that lists the content codings in the order in which 2999 they were applied. Note that the coding named "identity" is reserved 3000 for its special role in Accept-Encoding, and thus SHOULD NOT be 3001 included. 3003 Additional information about the encoding parameters can be provided 3004 by other header fields not defined by this specification. 3006 Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings 3007 listed in Content-Encoding are a characteristic of the 3008 representation; the representation is defined in terms of the coded 3009 form, and all other metadata about the representation is about the 3010 coded form unless otherwise noted in the metadata definition. 3011 Typically, the representation is only decoded just prior to rendering 3012 or analogous usage. 3014 If the media type includes an inherent encoding, such as a data 3015 format that is always compressed, then that encoding would not be 3016 restated in Content-Encoding even if it happens to be the same 3017 algorithm as one of the content codings. Such a content coding would 3018 only be listed if, for some bizarre reason, it is applied a second 3019 time to form the representation. Likewise, an origin server might 3020 choose to publish the same data as multiple representations that 3021 differ only in whether the coding is defined as part of Content-Type 3022 or Content-Encoding, since some user agents will behave differently 3023 in their handling of each response (e.g., open a "Save as ..." dialog 3024 instead of automatic decompression and rendering of content). 3026 An origin server MAY respond with a status code of 415 (Unsupported 3027 Media Type) if a representation in the request message has a content 3028 coding that is not acceptable. 3030 8.4.1. Content Codings 3032 Content coding values indicate an encoding transformation that has 3033 been or can be applied to a representation. Content codings are 3034 primarily used to allow a representation to be compressed or 3035 otherwise usefully transformed without losing the identity of its 3036 underlying media type and without loss of information. Frequently, 3037 the representation is stored in coded form, transmitted directly, and 3038 only decoded by the final recipient. 3040 content-coding = token 3042 All content codings are case-insensitive and ought to be registered 3043 within the "HTTP Content Coding Registry", as described in 3044 Section 16.6 3046 Content-coding values are used in the Accept-Encoding 3047 (Section 12.5.3) and Content-Encoding (Section 8.4) header fields. 3049 8.4.1.1. Compress Coding 3051 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding 3052 [Welch] that is commonly produced by the UNIX file compression 3053 program "compress". A recipient SHOULD consider "x-compress" to be 3054 equivalent to "compress". 3056 8.4.1.2. Deflate Coding 3058 The "deflate" coding is a "zlib" data format [RFC1950] containing a 3059 "deflate" compressed data stream [RFC1951] that uses a combination of 3060 the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. 3062 | *Note:* Some non-conformant implementations send the "deflate" 3063 | compressed data without the zlib wrapper. 3065 8.4.1.3. Gzip Coding 3067 The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy 3068 Check (CRC) that is commonly produced by the gzip file compression 3069 program [RFC1952]. A recipient SHOULD consider "x-gzip" to be 3070 equivalent to "gzip". 3072 8.5. Content-Language 3074 The "Content-Language" header field describes the natural language(s) 3075 of the intended audience for the representation. Note that this 3076 might not be equivalent to all the languages used within the 3077 representation. 3079 Content-Language = #language-tag 3081 Language tags are defined in Section 8.5.1. The primary purpose of 3082 Content-Language is to allow a user to identify and differentiate 3083 representations according to the users' own preferred language. 3084 Thus, if the content is intended only for a Danish-literate audience, 3085 the appropriate field is 3087 Content-Language: da 3089 If no Content-Language is specified, the default is that the content 3090 is intended for all language audiences. This might mean that the 3091 sender does not consider it to be specific to any natural language, 3092 or that the sender does not know for which language it is intended. 3094 Multiple languages MAY be listed for content that is intended for 3095 multiple audiences. For example, a rendition of the "Treaty of 3096 Waitangi", presented simultaneously in the original Maori and English 3097 versions, would call for 3099 Content-Language: mi, en 3101 However, just because multiple languages are present within a 3102 representation does not mean that it is intended for multiple 3103 linguistic audiences. An example would be a beginner's language 3104 primer, such as "A First Lesson in Latin", which is clearly intended 3105 to be used by an English-literate audience. In this case, the 3106 Content-Language would properly only include "en". 3108 Content-Language MAY be applied to any media type - it is not limited 3109 to textual documents. 3111 8.5.1. Language Tags 3113 A language tag, as defined in [RFC5646], identifies a natural 3114 language spoken, written, or otherwise conveyed by human beings for 3115 communication of information to other human beings. Computer 3116 languages are explicitly excluded. 3118 HTTP uses language tags within the Accept-Language and 3119 Content-Language header fields. Accept-Language uses the broader 3120 language-range production defined in Section 12.5.4, whereas 3121 Content-Language uses the language-tag production defined below. 3123 language-tag = 3125 A language tag is a sequence of one or more case-insensitive subtags, 3126 each separated by a hyphen character ("-", %x2D). In most cases, a 3127 language tag consists of a primary language subtag that identifies a 3128 broad family of related languages (e.g., "en" = English), which is 3129 optionally followed by a series of subtags that refine or narrow that 3130 language's range (e.g., "en-CA" = the variety of English as 3131 communicated in Canada). Whitespace is not allowed within a language 3132 tag. Example tags include: 3134 fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 3136 See [RFC5646] for further information. 3138 8.6. Content-Length 3140 The "Content-Length" header field indicates the associated 3141 representation's data length as a decimal non-negative integer number 3142 of octets. When transferring a representation as content, Content- 3143 Length refers specifically to the amount of data enclosed so that it 3144 can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In 3145 other cases, Content-Length indicates the selected representation's 3146 current length, which can be used by recipients to estimate transfer 3147 time or compare to previously stored representations. 3149 Content-Length = 1*DIGIT 3151 An example is 3153 Content-Length: 3495 3155 A user agent SHOULD send Content-Length in a request when the method 3156 defines a meaning for enclosed content and it is not sending 3157 Transfer-Encoding. For example, a user agent normally sends Content- 3158 Length in a POST request even when the value is 0 (indicating empty 3159 content). A user agent SHOULD NOT send a Content-Length header field 3160 when the request message does not contain content and the method 3161 semantics do not anticipate such data. 3163 A server MAY send a Content-Length header field in a response to a 3164 HEAD request (Section 9.3.2); a server MUST NOT send Content-Length 3165 in such a response unless its field value equals the decimal number 3166 of octets that would have been sent in the content of a response if 3167 the same request had used the GET method. 3169 A server MAY send a Content-Length header field in a 304 (Not 3170 Modified) response to a conditional GET request (Section 15.4.5); a 3171 server MUST NOT send Content-Length in such a response unless its 3172 field value equals the decimal number of octets that would have been 3173 sent in the content of a 200 (OK) response to the same request. 3175 A server MUST NOT send a Content-Length header field in any response 3176 with a status code of 1xx (Informational) or 204 (No Content). A 3177 server MUST NOT send a Content-Length header field in any 2xx 3178 (Successful) response to a CONNECT request (Section 9.3.6). 3180 Aside from the cases defined above, in the absence of Transfer- 3181 Encoding, an origin server SHOULD send a Content-Length header field 3182 when the content size is known prior to sending the complete header 3183 section. This will allow downstream recipients to measure transfer 3184 progress, know when a received message is complete, and potentially 3185 reuse the connection for additional requests. 3187 Any Content-Length field value greater than or equal to zero is 3188 valid. Since there is no predefined limit to the length of content, 3189 a recipient MUST anticipate potentially large decimal numerals and 3190 prevent parsing errors due to integer conversion overflows or 3191 precision loss due to integer conversion (Section 17.5). 3193 Because Content-Length is used for message delimitation in HTTP/1.1, 3194 its field value can impact how the message is parsed by downstream 3195 recipients even when the immediate connection is not using HTTP/1.1. 3196 If the message is forwarded by a downstream intermediary, a Content- 3197 Length field value that is inconsistent with the received message 3198 framing might cause a security failure due to request smuggling or 3199 response splitting. 3201 As a result, a sender MUST NOT forward a message with a Content- 3202 Length header field value that is known to be incorrect. 3204 Likewise, a sender MUST NOT forward a message with a Content-Length 3205 header field value that does not match the ABNF above, with one 3206 exception: A recipient of a Content-Length header field value 3207 consisting of the same decimal value repeated as a comma-separated 3208 list (e.g, "Content-Length: 42, 42"), MAY either reject the message 3209 as invalid or replace that invalid field value with a single instance 3210 of the decimal value, since this likely indicates that a duplicate 3211 was generated or combined by an upstream message processor. 3213 8.7. Content-Location 3215 The "Content-Location" header field references a URI that can be used 3216 as an identifier for a specific resource corresponding to the 3217 representation in this message's content. In other words, if one 3218 were to perform a GET request on this URI at the time of this 3219 message's generation, then a 200 (OK) response would contain the same 3220 representation that is enclosed as content in this message. 3222 Content-Location = absolute-URI / partial-URI 3224 The field value is either an absolute-URI or a partial-URI. In the 3225 latter case (Section 4), the referenced URI is relative to the target 3226 URI ([URI], Section 5). 3228 The Content-Location value is not a replacement for the target URI 3229 (Section 7.1). It is representation metadata. It has the same 3230 syntax and semantics as the header field of the same name defined for 3231 MIME body parts in Section 4 of [RFC2557]. However, its appearance 3232 in an HTTP message has some special implications for HTTP recipients. 3234 If Content-Location is included in a 2xx (Successful) response 3235 message and its value refers (after conversion to absolute form) to a 3236 URI that is the same as the target URI, then the recipient MAY 3237 consider the content to be a current representation of that resource 3238 at the time indicated by the message origination date. For a GET 3239 (Section 9.3.1) or HEAD (Section 9.3.2) request, this is the same as 3240 the default semantics when no Content-Location is provided by the 3241 server. For a state-changing request like PUT (Section 9.3.4) or 3242 POST (Section 9.3.3), it implies that the server's response contains 3243 the new representation of that resource, thereby distinguishing it 3244 from representations that might only report about the action (e.g., 3245 "It worked!"). This allows authoring applications to update their 3246 local copies without the need for a subsequent GET request. 3248 If Content-Location is included in a 2xx (Successful) response 3249 message and its field value refers to a URI that differs from the 3250 target URI, then the origin server claims that the URI is an 3251 identifier for a different resource corresponding to the enclosed 3252 representation. Such a claim can only be trusted if both identifiers 3253 share the same resource owner, which cannot be programmatically 3254 determined via HTTP. 3256 * For a response to a GET or HEAD request, this is an indication 3257 that the target URI refers to a resource that is subject to 3258 content negotiation and the Content-Location field value is a more 3259 specific identifier for the selected representation. 3261 * For a 201 (Created) response to a state-changing method, a 3262 Content-Location field value that is identical to the Location 3263 field value indicates that this content is a current 3264 representation of the newly created resource. 3266 * Otherwise, such a Content-Location indicates that this content is 3267 a representation reporting on the requested action's status and 3268 that the same report is available (for future access with GET) at 3269 the given URI. For example, a purchase transaction made via a 3270 POST request might include a receipt document as the content of 3271 the 200 (OK) response; the Content-Location field value provides 3272 an identifier for retrieving a copy of that same receipt in the 3273 future. 3275 A user agent that sends Content-Location in a request message is 3276 stating that its value refers to where the user agent originally 3277 obtained the content of the enclosed representation (prior to any 3278 modifications made by that user agent). In other words, the user 3279 agent is providing a back link to the source of the original 3280 representation. 3282 An origin server that receives a Content-Location field in a request 3283 message MUST treat the information as transitory request context 3284 rather than as metadata to be saved verbatim as part of the 3285 representation. An origin server MAY use that context to guide in 3286 processing the request or to save it for other uses, such as within 3287 source links or versioning metadata. However, an origin server MUST 3288 NOT use such context information to alter the request semantics. 3290 For example, if a client makes a PUT request on a negotiated resource 3291 and the origin server accepts that PUT (without redirection), then 3292 the new state of that resource is expected to be consistent with the 3293 one representation supplied in that PUT; the Content-Location cannot 3294 be used as a form of reverse content selection identifier to update 3295 only one of the negotiated representations. If the user agent had 3296 wanted the latter semantics, it would have applied the PUT directly 3297 to the Content-Location URI. 3299 8.8. Validator Fields 3301 Validator fields convey metadata about the selected representation 3302 (Section 3.2). In responses to safe requests, validator fields 3303 describe the selected representation chosen by the origin server 3304 while handling the response. Note that, depending on the status code 3305 semantics, the selected representation for a given response is not 3306 necessarily the same as the representation enclosed as response 3307 content. 3309 In a successful response to a state-changing request, validator 3310 fields describe the new representation that has replaced the prior 3311 selected representation as a result of processing the request. 3313 For example, an ETag field in a 201 (Created) response communicates 3314 the entity-tag of the newly created resource's representation, so 3315 that it can be used in later conditional requests to prevent the 3316 "lost update" problem (Section 13.1). 3318 This specification defines two forms of metadata that are commonly 3319 used to observe resource state and test for preconditions: 3320 modification dates (Section 8.8.2) and opaque entity tags 3321 (Section 8.8.3). Additional metadata that reflects resource state 3322 has been defined by various extensions of HTTP, such as Web 3323 Distributed Authoring and Versioning [WEBDAV], that are beyond the 3324 scope of this specification. A resource metadata value is referred 3325 to as a _validator_ when it is used within a precondition. 3327 8.8.1. Weak versus Strong 3329 Validators come in two flavors: strong or weak. Weak validators are 3330 easy to generate but are far less useful for comparisons. Strong 3331 validators are ideal for comparisons but can be very difficult (and 3332 occasionally impossible) to generate efficiently. Rather than impose 3333 that all forms of resource adhere to the same strength of validator, 3334 HTTP exposes the type of validator in use and imposes restrictions on 3335 when weak validators can be used as preconditions. 3337 A _strong validator_ is representation metadata that changes value 3338 whenever a change occurs to the representation data that would be 3339 observable in the content of a 200 (OK) response to GET. 3341 A strong validator might change for reasons other than a change to 3342 the representation data, such as when a semantically significant part 3343 of the representation metadata is changed (e.g., Content-Type), but 3344 it is in the best interests of the origin server to only change the 3345 value when it is necessary to invalidate the stored responses held by 3346 remote caches and authoring tools. 3348 Cache entries might persist for arbitrarily long periods, regardless 3349 of expiration times. Thus, a cache might attempt to validate an 3350 entry using a validator that it obtained in the distant past. A 3351 strong validator is unique across all versions of all representations 3352 associated with a particular resource over time. However, there is 3353 no implication of uniqueness across representations of different 3354 resources (i.e., the same strong validator might be in use for 3355 representations of multiple resources at the same time and does not 3356 imply that those representations are equivalent). 3358 There are a variety of strong validators used in practice. The best 3359 are based on strict revision control, wherein each change to a 3360 representation always results in a unique node name and revision 3361 identifier being assigned before the representation is made 3362 accessible to GET. A collision-resistant hash function applied to 3363 the representation data is also sufficient if the data is available 3364 prior to the response header fields being sent and the digest does 3365 not need to be recalculated every time a validation request is 3366 received. However, if a resource has distinct representations that 3367 differ only in their metadata, such as might occur with content 3368 negotiation over media types that happen to share the same data 3369 format, then the origin server needs to incorporate additional 3370 information in the validator to distinguish those representations. 3372 In contrast, a _weak validator_ is representation metadata that might 3373 not change for every change to the representation data. This 3374 weakness might be due to limitations in how the value is calculated, 3375 such as clock resolution, an inability to ensure uniqueness for all 3376 possible representations of the resource, or a desire of the resource 3377 owner to group representations by some self-determined set of 3378 equivalency rather than unique sequences of data. An origin server 3379 SHOULD change a weak entity-tag whenever it considers prior 3380 representations to be unacceptable as a substitute for the current 3381 representation. In other words, a weak entity-tag ought to change 3382 whenever the origin server wants caches to invalidate old responses. 3384 For example, the representation of a weather report that changes in 3385 content every second, based on dynamic measurements, might be grouped 3386 into sets of equivalent representations (from the origin server's 3387 perspective) with the same weak validator in order to allow cached 3388 representations to be valid for a reasonable period of time (perhaps 3389 adjusted dynamically based on server load or weather quality). 3390 Likewise, a representation's modification time, if defined with only 3391 one-second resolution, might be a weak validator if it is possible 3392 for the representation to be modified twice during a single second 3393 and retrieved between those modifications. 3395 Likewise, a validator is weak if it is shared by two or more 3396 representations of a given resource at the same time, unless those 3397 representations have identical representation data. For example, if 3398 the origin server sends the same validator for a representation with 3399 a gzip content coding applied as it does for a representation with no 3400 content coding, then that validator is weak. However, two 3401 simultaneous representations might share the same strong validator if 3402 they differ only in the representation metadata, such as when two 3403 different media types are available for the same representation data. 3405 Strong validators are usable for all conditional requests, including 3406 cache validation, partial content ranges, and "lost update" 3407 avoidance. Weak validators are only usable when the client does not 3408 require exact equality with previously obtained representation data, 3409 such as when validating a cache entry or limiting a web traversal to 3410 recent changes. 3412 8.8.2. Last-Modified 3414 The "Last-Modified" header field in a response provides a timestamp 3415 indicating the date and time at which the origin server believes the 3416 selected representation was last modified, as determined at the 3417 conclusion of handling the request. 3419 Last-Modified = HTTP-date 3421 An example of its use is 3422 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 3424 8.8.2.1. Generation 3426 An origin server SHOULD send Last-Modified for any selected 3427 representation for which a last modification date can be reasonably 3428 and consistently determined, since its use in conditional requests 3429 and evaluating cache freshness ([CACHING]) can substantially reduce 3430 unnecessary transfers and significantly improve service availability 3431 and scalability. 3433 A representation is typically the sum of many parts behind the 3434 resource interface. The last-modified time would usually be the most 3435 recent time that any of those parts were changed. How that value is 3436 determined for any given resource is an implementation detail beyond 3437 the scope of this specification. 3439 An origin server SHOULD obtain the Last-Modified value of the 3440 representation as close as possible to the time that it generates the 3441 Date field value for its response. This allows a recipient to make 3442 an accurate assessment of the representation's modification time, 3443 especially if the representation changes near the time that the 3444 response is generated. 3446 An origin server with a clock MUST NOT send a Last-Modified date that 3447 is later than the server's time of message origination (Date). If 3448 the last modification time is derived from implementation-specific 3449 metadata that evaluates to some time in the future, according to the 3450 origin server's clock, then the origin server MUST replace that value 3451 with the message origination date. This prevents a future 3452 modification date from having an adverse impact on cache validation. 3454 An origin server without a clock MUST NOT assign Last-Modified values 3455 to a response unless these values were associated with the resource 3456 by some other system or user with a reliable clock. 3458 8.8.2.2. Comparison 3460 A Last-Modified time, when used as a validator in a request, is 3461 implicitly weak unless it is possible to deduce that it is strong, 3462 using the following rules: 3464 * The validator is being compared by an origin server to the actual 3465 current validator for the representation and, 3467 * That origin server reliably knows that the associated 3468 representation did not change twice during the second covered by 3469 the presented validator; 3471 or 3473 * The validator is about to be used by a client in an 3474 If-Modified-Since, If-Unmodified-Since, or If-Range header field, 3475 because the client has a cache entry for the associated 3476 representation, and 3478 * That cache entry includes a Date value which is at least one 3479 second after the Last-Modified value and the client has reason to 3480 believe that they were generated by the same clock or that there 3481 is enough difference between the Last-Modified and Date values to 3482 make clock synchronization issues unlikely; 3484 or 3486 * The validator is being compared by an intermediate cache to the 3487 validator stored in its cache entry for the representation, and 3489 * That cache entry includes a Date value which is at least one 3490 second after the Last-Modified value and the cache has reason to 3491 believe that they were generated by the same clock or that there 3492 is enough difference between the Last-Modified and Date values to 3493 make clock synchronization issues unlikely. 3495 This method relies on the fact that if two different responses were 3496 sent by the origin server during the same second, but both had the 3497 same Last-Modified time, then at least one of those responses would 3498 have a Date value equal to its Last-Modified time. 3500 8.8.3. ETag 3502 The "ETag" field in a response provides the current entity-tag for 3503 the selected representation, as determined at the conclusion of 3504 handling the request. An entity-tag is an opaque validator for 3505 differentiating between multiple representations of the same 3506 resource, regardless of whether those multiple representations are 3507 due to resource state changes over time, content negotiation 3508 resulting in multiple representations being valid at the same time, 3509 or both. An entity-tag consists of an opaque quoted string, possibly 3510 prefixed by a weakness indicator. 3512 ETag = entity-tag 3514 entity-tag = [ weak ] opaque-tag 3515 weak = %s"W/" 3516 opaque-tag = DQUOTE *etagc DQUOTE 3517 etagc = %x21 / %x23-7E / obs-text 3518 ; VCHAR except double quotes, plus obs-text 3520 | *Note:* Previously, opaque-tag was defined to be a quoted- 3521 | string ([RFC2616], Section 3.11); thus, some recipients might 3522 | perform backslash unescaping. Servers therefore ought to avoid 3523 | backslash characters in entity tags. 3525 An entity-tag can be more reliable for validation than a modification 3526 date in situations where it is inconvenient to store modification 3527 dates, where the one-second resolution of HTTP date values is not 3528 sufficient, or where modification dates are not consistently 3529 maintained. 3531 Examples: 3533 ETag: "xyzzy" 3534 ETag: W/"xyzzy" 3535 ETag: "" 3537 An entity-tag can be either a weak or strong validator, with strong 3538 being the default. If an origin server provides an entity-tag for a 3539 representation and the generation of that entity-tag does not satisfy 3540 all of the characteristics of a strong validator (Section 8.8.1), 3541 then the origin server MUST mark the entity-tag as weak by prefixing 3542 its opaque value with "W/" (case-sensitive). 3544 A sender MAY send the Etag field in a trailer section (see 3545 Section 6.5). However, since trailers are often ignored, it is 3546 preferable to send Etag as a header field unless the entity-tag is 3547 generated while sending the content. 3549 8.8.3.1. Generation 3551 The principle behind entity-tags is that only the service author 3552 knows the implementation of a resource well enough to select the most 3553 accurate and efficient validation mechanism for that resource, and 3554 that any such mechanism can be mapped to a simple sequence of octets 3555 for easy comparison. Since the value is opaque, there is no need for 3556 the client to be aware of how each entity-tag is constructed. 3558 For example, a resource that has implementation-specific versioning 3559 applied to all changes might use an internal revision number, perhaps 3560 combined with a variance identifier for content negotiation, to 3561 accurately differentiate between representations. Other 3562 implementations might use a collision-resistant hash of 3563 representation content, a combination of various file attributes, or 3564 a modification timestamp that has sub-second resolution. 3566 An origin server SHOULD send an ETag for any selected representation 3567 for which detection of changes can be reasonably and consistently 3568 determined, since the entity-tag's use in conditional requests and 3569 evaluating cache freshness ([CACHING]) can substantially reduce 3570 unnecessary transfers and significantly improve service availability, 3571 scalability, and reliability. 3573 8.8.3.2. Comparison 3575 There are two entity-tag comparison functions, depending on whether 3576 or not the comparison context allows the use of weak validators: 3578 _Strong comparison_: two entity-tags are equivalent if both are not 3579 weak and their opaque-tags match character-by-character. 3581 _Weak comparison_: two entity-tags are equivalent if their opaque- 3582 tags match character-by-character, regardless of either or both 3583 being tagged as "weak". 3585 The example below shows the results for a set of entity-tag pairs and 3586 both the weak and strong comparison function results: 3588 +========+========+===================+=================+ 3589 | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | 3590 +========+========+===================+=================+ 3591 | W/"1" | W/"1" | no match | match | 3592 +--------+--------+-------------------+-----------------+ 3593 | W/"1" | W/"2" | no match | no match | 3594 +--------+--------+-------------------+-----------------+ 3595 | W/"1" | "1" | no match | match | 3596 +--------+--------+-------------------+-----------------+ 3597 | "1" | "1" | match | match | 3598 +--------+--------+-------------------+-----------------+ 3600 Table 3 3602 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 3604 Consider a resource that is subject to content negotiation 3605 (Section 12), and where the representations sent in response to a GET 3606 request vary based on the Accept-Encoding request header field 3607 (Section 12.5.3): 3609 >> Request: 3611 GET /index HTTP/1.1 3612 Host: www.example.com 3613 Accept-Encoding: gzip 3614 In this case, the response might or might not use the gzip content 3615 coding. If it does not, the response might look like: 3617 >> Response: 3619 HTTP/1.1 200 OK 3620 Date: Fri, 26 Mar 2010 00:05:00 GMT 3621 ETag: "123-a" 3622 Content-Length: 70 3623 Vary: Accept-Encoding 3624 Content-Type: text/plain 3626 Hello World! 3627 Hello World! 3628 Hello World! 3629 Hello World! 3630 Hello World! 3632 An alternative representation that does use gzip content coding would 3633 be: 3635 >> Response: 3637 HTTP/1.1 200 OK 3638 Date: Fri, 26 Mar 2010 00:05:00 GMT 3639 ETag: "123-b" 3640 Content-Length: 43 3641 Vary: Accept-Encoding 3642 Content-Type: text/plain 3643 Content-Encoding: gzip 3645 ...binary data... 3647 | *Note:* Content codings are a property of the representation 3648 | data, so a strong entity-tag for a content-encoded 3649 | representation has to be distinct from the entity tag of an 3650 | unencoded representation to prevent potential conflicts during 3651 | cache updates and range requests. In contrast, transfer 3652 | codings (Section 7 of [HTTP/1.1]) apply only during message 3653 | transfer and do not result in distinct entity-tags. 3655 8.8.4. When to Use Entity-Tags and Last-Modified Dates 3657 In 200 (OK) responses to GET or HEAD, an origin server: 3659 * SHOULD send an entity-tag validator unless it is not feasible to 3660 generate one. 3662 * MAY send a weak entity-tag instead of a strong entity-tag, if 3663 performance considerations support the use of weak entity-tags, or 3664 if it is unfeasible to send a strong entity-tag. 3666 * SHOULD send a Last-Modified value if it is feasible to send one. 3668 In other words, the preferred behavior for an origin server is to 3669 send both a strong entity-tag and a Last-Modified value in successful 3670 responses to a retrieval request. 3672 A client: 3674 * MUST send that entity-tag in any cache validation request (using 3675 If-Match or If-None-Match) if an entity-tag has been provided by 3676 the origin server. 3678 * SHOULD send the Last-Modified value in non-subrange cache 3679 validation requests (using If-Modified-Since) if only a Last- 3680 Modified value has been provided by the origin server. 3682 * MAY send the Last-Modified value in subrange cache validation 3683 requests (using If-Unmodified-Since) if only a Last-Modified value 3684 has been provided by an HTTP/1.0 origin server. The user agent 3685 SHOULD provide a way to disable this, in case of difficulty. 3687 * SHOULD send both validators in cache validation requests if both 3688 an entity-tag and a Last-Modified value have been provided by the 3689 origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to 3690 respond appropriately. 3692 9. Methods 3694 9.1. Overview 3696 The request method token is the primary source of request semantics; 3697 it indicates the purpose for which the client has made this request 3698 and what is expected by the client as a successful result. 3700 The request method's semantics might be further specialized by the 3701 semantics of some header fields when present in a request if those 3702 additional semantics do not conflict with the method. For example, a 3703 client can send conditional request header fields (Section 13.1) to 3704 make the requested action conditional on the current state of the 3705 target resource. 3707 HTTP is designed to be usable as an interface to distributed object 3708 systems. The request method invokes an action to be applied to a 3709 target resource in much the same way that a remote method invocation 3710 can be sent to an identified object. 3712 method = token 3714 The method token is case-sensitive because it might be used as a 3715 gateway to object-based systems with case-sensitive method names. By 3716 convention, standardized methods are defined in all-uppercase US- 3717 ASCII letters. 3719 Unlike distributed objects, the standardized request methods in HTTP 3720 are not resource-specific, since uniform interfaces provide for 3721 better visibility and reuse in network-based systems [REST]. Once 3722 defined, a standardized method ought to have the same semantics when 3723 applied to any resource, though each resource determines for itself 3724 whether those semantics are implemented or allowed. 3726 This specification defines a number of standardized methods that are 3727 commonly used in HTTP, as outlined by the following table. 3729 +=========+============================================+=======+ 3730 | Method | Description | Ref. | 3731 +=========+============================================+=======+ 3732 | GET | Transfer a current representation of the | 9.3.1 | 3733 | | target resource. | | 3734 +---------+--------------------------------------------+-------+ 3735 | HEAD | Same as GET, but do not transfer the | 9.3.2 | 3736 | | response content. | | 3737 +---------+--------------------------------------------+-------+ 3738 | POST | Perform resource-specific processing on | 9.3.3 | 3739 | | the request content. | | 3740 +---------+--------------------------------------------+-------+ 3741 | PUT | Replace all current representations of the | 9.3.4 | 3742 | | target resource with the request content. | | 3743 +---------+--------------------------------------------+-------+ 3744 | DELETE | Remove all current representations of the | 9.3.5 | 3745 | | target resource. | | 3746 +---------+--------------------------------------------+-------+ 3747 | CONNECT | Establish a tunnel to the server | 9.3.6 | 3748 | | identified by the target resource. | | 3749 +---------+--------------------------------------------+-------+ 3750 | OPTIONS | Describe the communication options for the | 9.3.7 | 3751 | | target resource. | | 3752 +---------+--------------------------------------------+-------+ 3753 | TRACE | Perform a message loop-back test along the | 9.3.8 | 3754 | | path to the target resource. | | 3755 +---------+--------------------------------------------+-------+ 3757 Table 4 3759 All general-purpose servers MUST support the methods GET and HEAD. 3760 All other methods are OPTIONAL. 3762 The set of methods allowed by a target resource can be listed in an 3763 Allow header field (Section 10.2.1). However, the set of allowed 3764 methods can change dynamically. An origin server that receives a 3765 request method that is unrecognized or not implemented SHOULD respond 3766 with the 501 (Not Implemented) status code. An origin server that 3767 receives a request method that is recognized and implemented, but not 3768 allowed for the target resource, SHOULD respond with the 405 (Method 3769 Not Allowed) status code. 3771 Additional methods, outside the scope of this specification, have 3772 been specified for use in HTTP. All such methods ought to be 3773 registered within the "Hypertext Transfer Protocol (HTTP) Method 3774 Registry", as described in Section 16.1. 3776 9.2. Common Method Properties 3778 9.2.1. Safe Methods 3780 Request methods are considered _safe_ if their defined semantics are 3781 essentially read-only; i.e., the client does not request, and does 3782 not expect, any state change on the origin server as a result of 3783 applying a safe method to a target resource. Likewise, reasonable 3784 use of a safe method is not expected to cause any harm, loss of 3785 property, or unusual burden on the origin server. 3787 This definition of safe methods does not prevent an implementation 3788 from including behavior that is potentially harmful, that is not 3789 entirely read-only, or that causes side effects while invoking a safe 3790 method. What is important, however, is that the client did not 3791 request that additional behavior and cannot be held accountable for 3792 it. For example, most servers append request information to access 3793 log files at the completion of every response, regardless of the 3794 method, and that is considered safe even though the log storage might 3795 become full and cause the server to fail. Likewise, a safe request 3796 initiated by selecting an advertisement on the Web will often have 3797 the side effect of charging an advertising account. 3799 Of the request methods defined by this specification, the GET, HEAD, 3800 OPTIONS, and TRACE methods are defined to be safe. 3802 The purpose of distinguishing between safe and unsafe methods is to 3803 allow automated retrieval processes (spiders) and cache performance 3804 optimization (pre-fetching) to work without fear of causing harm. In 3805 addition, it allows a user agent to apply appropriate constraints on 3806 the automated use of unsafe methods when processing potentially 3807 untrusted content. 3809 A user agent SHOULD distinguish between safe and unsafe methods when 3810 presenting potential actions to a user, such that the user can be 3811 made aware of an unsafe action before it is requested. 3813 When a resource is constructed such that parameters within the target 3814 URI have the effect of selecting an action, it is the resource 3815 owner's responsibility to ensure that the action is consistent with 3816 the request method semantics. For example, it is common for Web- 3817 based content editing software to use actions within query 3818 parameters, such as "page?do=delete". If the purpose of such a 3819 resource is to perform an unsafe action, then the resource owner MUST 3820 disable or disallow that action when it is accessed using a safe 3821 request method. Failure to do so will result in unfortunate side 3822 effects when automated processes perform a GET on every URI reference 3823 for the sake of link maintenance, pre-fetching, building a search 3824 index, etc. 3826 9.2.2. Idempotent Methods 3828 A request method is considered _idempotent_ if the intended effect on 3829 the server of multiple identical requests with that method is the 3830 same as the effect for a single such request. Of the request methods 3831 defined by this specification, PUT, DELETE, and safe request methods 3832 are idempotent. 3834 Like the definition of safe, the idempotent property only applies to 3835 what has been requested by the user; a server is free to log each 3836 request separately, retain a revision control history, or implement 3837 other non-idempotent side effects for each idempotent request. 3839 Idempotent methods are distinguished because the request can be 3840 repeated automatically if a communication failure occurs before the 3841 client is able to read the server's response. For example, if a 3842 client sends a PUT request and the underlying connection is closed 3843 before any response is received, then the client can establish a new 3844 connection and retry the idempotent request. It knows that repeating 3845 the request will have the same intended effect, even if the original 3846 request succeeded, though the response might differ. 3848 A client SHOULD NOT automatically retry a request with a non- 3849 idempotent method unless it has some means to know that the request 3850 semantics are actually idempotent, regardless of the method, or some 3851 means to detect that the original request was never applied. 3853 For example, a user agent can repeat a POST request automatically if 3854 it knows (through design or configuration) that the request is safe 3855 for that resource. Likewise, a user agent designed specifically to 3856 operate on a version control repository might be able to recover from 3857 partial failure conditions by checking the target resource 3858 revision(s) after a failed connection, reverting or fixing any 3859 changes that were partially applied, and then automatically retrying 3860 the requests that failed. 3862 Some clients take a riskier approach and attempt to guess when an 3863 automatic retry is possible. For example, a client might 3864 automatically retry a POST request if the underlying transport 3865 connection closed before any part of a response is received, 3866 particularly if an idle persistent connection was used. 3868 A proxy MUST NOT automatically retry non-idempotent requests. A 3869 client SHOULD NOT automatically retry a failed automatic retry. 3871 9.2.3. Methods and Caching 3873 For a cache to store and use a response, the associated method needs 3874 to explicitly allow caching, and detail under what conditions a 3875 response can be used to satisfy subsequent requests; a method 3876 definition which does not do so cannot be cached. For additional 3877 requirements see [CACHING]. 3879 This specification defines caching semantics for GET, HEAD, and POST, 3880 although the overwhelming majority of cache implementations only 3881 support GET and HEAD. 3883 9.3. Method Definitions 3885 9.3.1. GET 3887 The GET method requests transfer of a current selected representation 3888 for the target resource. A successful response reflects the quality 3889 of "sameness" identified by the target URI (Section 1.2.2 of [URI]). 3890 Hence, retrieving identifiable information via HTTP is usually 3891 performed by making a GET request on an identifier associated with 3892 the potential for providing that information in a 200 (OK) response. 3894 GET is the primary mechanism of information retrieval and the focus 3895 of almost all performance optimizations. Applications that produce a 3896 URI for each important resource can benefit from those optimizations 3897 while enabling their reuse by other applications, creating a network 3898 effect that promotes further expansion of the Web. 3900 It is tempting to think of resource identifiers as remote file system 3901 pathnames and of representations as being a copy of the contents of 3902 such files. In fact, that is how many resources are implemented (see 3903 Section 17.3 for related security considerations). However, there 3904 are no such limitations in practice. 3906 The HTTP interface for a resource is just as likely to be implemented 3907 as a tree of content objects, a programmatic view on various database 3908 records, or a gateway to other information systems. Even when the 3909 URI mapping mechanism is tied to a file system, an origin server 3910 might be configured to execute the files with the request as input 3911 and send the output as the representation rather than transfer the 3912 files directly. Regardless, only the origin server needs to know how 3913 each resource identifier corresponds to an implementation and how 3914 that implementation manages to select and send a current 3915 representation of the target resource. 3917 A client can alter the semantics of GET to be a "range request", 3918 requesting transfer of only some part(s) of the selected 3919 representation, by sending a Range header field in the request 3920 (Section 14.2). 3922 Although request message framing is independent of the method used, 3923 content received in a GET request has no generally defined semantics, 3924 cannot alter the meaning or target of the request, and might lead 3925 some implementations to reject the request and close the connection 3926 because of its potential as a request smuggling attack (Section 11.2 3927 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET 3928 request unless it is made directly to an origin server that has 3929 previously indicated, in or out of band, that such a request has a 3930 purpose and will be adequately supported. An origin server SHOULD 3931 NOT rely on private agreements to receive content, since participants 3932 in HTTP communication are often unaware of intermediaries along the 3933 request chain. 3935 The response to a GET request is cacheable; a cache MAY use it to 3936 satisfy subsequent GET and HEAD requests unless otherwise indicated 3937 by the Cache-Control header field (Section 5.2 of [CACHING]). 3939 When information retrieval is performed with a mechanism that 3940 constructs a target URI from user-provided information, such as the 3941 query fields of a form using GET, potentially sensitive data might be 3942 provided that would not be appropriate for disclosure within a URI 3943 (see Section 17.9). In some cases, the data can be filtered or 3944 transformed such that it would not reveal such information. In 3945 others, particularly when there is no benefit from caching a 3946 response, using the POST method (Section 9.3.3) instead of GET can 3947 transmit such information in the request content rather than within 3948 the target URI. 3950 9.3.2. HEAD 3952 The HEAD method is identical to GET except that the server MUST NOT 3953 send content in the response. HEAD is used to obtain metadata about 3954 the selected representation without transferring its representation 3955 data, often for the sake of testing hypertext links or finding recent 3956 modifications. 3958 The server SHOULD send the same header fields in response to a HEAD 3959 request as it would have sent if the request method had been GET. 3960 However, a server MAY omit header fields for which a value is 3961 determined only while generating the content. For example, some 3962 servers buffer a dynamic response to GET until a minimum amount of 3963 data is generated so that they can more efficiently delimit small 3964 responses or make late decisions with regard to content selection. 3965 Such a response to GET might contain Content-Length and Vary fields, 3966 for example, that are not generated within a HEAD response. These 3967 minor inconsistencies are considered preferable to generating and 3968 discarding the content for a HEAD request, since HEAD is usually 3969 requested for the sake of efficiency. 3971 Although request message framing is independent of the method used, 3972 content received in a HEAD request has no generally defined 3973 semantics, cannot alter the meaning or target of the request, and 3974 might lead some implementations to reject the request and close the 3975 connection because of its potential as a request smuggling attack 3976 (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content 3977 in a HEAD request unless it is made directly to an origin server that 3978 has previously indicated, in or out of band, that such a request has 3979 a purpose and will be adequately supported. An origin server SHOULD 3980 NOT rely on private agreements to receive content, since participants 3981 in HTTP communication are often unaware of intermediaries along the 3982 request chain. 3984 The response to a HEAD request is cacheable; a cache MAY use it to 3985 satisfy subsequent HEAD requests unless otherwise indicated by the 3986 Cache-Control header field (Section 5.2 of [CACHING]). A HEAD 3987 response might also affect previously cached responses to GET; see 3988 Section 4.3.5 of [CACHING]. 3990 9.3.3. POST 3992 The POST method requests that the target resource process the 3993 representation enclosed in the request according to the resource's 3994 own specific semantics. For example, POST is used for the following 3995 functions (among others): 3997 * Providing a block of data, such as the fields entered into an HTML 3998 form, to a data-handling process; 4000 * Posting a message to a bulletin board, newsgroup, mailing list, 4001 blog, or similar group of articles; 4003 * Creating a new resource that has yet to be identified by the 4004 origin server; and 4006 * Appending data to a resource's existing representation(s). 4008 An origin server indicates response semantics by choosing an 4009 appropriate status code depending on the result of processing the 4010 POST request; almost all of the status codes defined by this 4011 specification could be received in a response to POST (the exceptions 4012 being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not 4013 Satisfiable)). 4015 If one or more resources has been created on the origin server as a 4016 result of successfully processing a POST request, the origin server 4017 SHOULD send a 201 (Created) response containing a Location header 4018 field that provides an identifier for the primary resource created 4019 (Section 10.2.3) and a representation that describes the status of 4020 the request while referring to the new resource(s). 4022 Responses to POST requests are only cacheable when they include 4023 explicit freshness information (see Section 4.2.1 of [CACHING]) and a 4024 Content-Location header field that has the same value as the POST's 4025 target URI (Section 8.7). A cached POST response can be reused to 4026 satisfy a later GET or HEAD request, but not a POST request, since 4027 POST is required to be written through to the origin server, because 4028 it is unsafe; see Section 4 of [CACHING]. 4030 If the result of processing a POST would be equivalent to a 4031 representation of an existing resource, an origin server MAY redirect 4032 the user agent to that resource by sending a 303 (See Other) response 4033 with the existing resource's identifier in the Location field. This 4034 has the benefits of providing the user agent a resource identifier 4035 and transferring the representation via a method more amenable to 4036 shared caching, though at the cost of an extra request if the user 4037 agent does not already have the representation cached. 4039 9.3.4. PUT 4041 The PUT method requests that the state of the target resource be 4042 created or replaced with the state defined by the representation 4043 enclosed in the request message content. A successful PUT of a given 4044 representation would suggest that a subsequent GET on that same 4045 target resource will result in an equivalent representation being 4046 sent in a 200 (OK) response. However, there is no guarantee that 4047 such a state change will be observable, since the target resource 4048 might be acted upon by other user agents in parallel, or might be 4049 subject to dynamic processing by the origin server, before any 4050 subsequent GET is received. A successful response only implies that 4051 the user agent's intent was achieved at the time of its processing by 4052 the origin server. 4054 If the target resource does not have a current representation and the 4055 PUT successfully creates one, then the origin server MUST inform the 4056 user agent by sending a 201 (Created) response. If the target 4057 resource does have a current representation and that representation 4058 is successfully modified in accordance with the state of the enclosed 4059 representation, then the origin server MUST send either a 200 (OK) or 4060 a 204 (No Content) response to indicate successful completion of the 4061 request. 4063 An origin server SHOULD verify that the PUT representation is 4064 consistent with its configured constraints for the target resource. 4065 For example, if an origin server determines a resource's 4066 representation metadata based on the URI, then the origin server 4067 needs to ensure that the content received in a successful PUT request 4068 is consistent with that metadata. When a PUT representation is 4069 inconsistent with the target resource, the origin server SHOULD 4070 either make them consistent, by transforming the representation or 4071 changing the resource configuration, or respond with an appropriate 4072 error message containing sufficient information to explain why the 4073 representation is unsuitable. The 409 (Conflict) or 415 (Unsupported 4074 Media Type) status codes are suggested, with the latter being 4075 specific to constraints on Content-Type values. 4077 For example, if the target resource is configured to always have a 4078 Content-Type of "text/html" and the representation being PUT has a 4079 Content-Type of "image/jpeg", the origin server ought to do one of: 4081 a. reconfigure the target resource to reflect the new media type; 4083 b. transform the PUT representation to a format consistent with that 4084 of the resource before saving it as the new resource state; or, 4086 c. reject the request with a 415 (Unsupported Media Type) response 4087 indicating that the target resource is limited to "text/html", 4088 perhaps including a link to a different resource that would be a 4089 suitable target for the new representation. 4091 HTTP does not define exactly how a PUT method affects the state of an 4092 origin server beyond what can be expressed by the intent of the user 4093 agent request and the semantics of the origin server response. It 4094 does not define what a resource might be, in any sense of that word, 4095 beyond the interface provided via HTTP. It does not define how 4096 resource state is "stored", nor how such storage might change as a 4097 result of a change in resource state, nor how the origin server 4098 translates resource state into representations. Generally speaking, 4099 all implementation details behind the resource interface are 4100 intentionally hidden by the server. 4102 This extends to how header and trailer fields are stored; while 4103 common header fields like Content-Type will typically be stored and 4104 returned upon subsequent GET requests, header and trailer field 4105 handling is specific to the resource that received the request. As a 4106 result, an origin server SHOULD ignore unrecognized header and 4107 trailer fields received in a PUT request (i.e., not save them as part 4108 of the resource state). 4110 An origin server MUST NOT send a validator field (Section 8.8), such 4111 as an ETag or Last-Modified field, in a successful response to PUT 4112 unless the request's representation data was saved without any 4113 transformation applied to the content (i.e., the resource's new 4114 representation data is identical to the content received in the PUT 4115 request) and the validator field value reflects the new 4116 representation. This requirement allows a user agent to know when 4117 the representation it sent (and retains in memory) is the result of 4118 the PUT, and thus doesn't need to be retrieved again from the origin 4119 server. The new validator(s) received in the response can be used 4120 for future conditional requests in order to prevent accidental 4121 overwrites (Section 13.1). 4123 The fundamental difference between the POST and PUT methods is 4124 highlighted by the different intent for the enclosed representation. 4125 The target resource in a POST request is intended to handle the 4126 enclosed representation according to the resource's own semantics, 4127 whereas the enclosed representation in a PUT request is defined as 4128 replacing the state of the target resource. Hence, the intent of PUT 4129 is idempotent and visible to intermediaries, even though the exact 4130 effect is only known by the origin server. 4132 Proper interpretation of a PUT request presumes that the user agent 4133 knows which target resource is desired. A service that selects a 4134 proper URI on behalf of the client, after receiving a state-changing 4135 request, SHOULD be implemented using the POST method rather than PUT. 4136 If the origin server will not make the requested PUT state change to 4137 the target resource and instead wishes to have it applied to a 4138 different resource, such as when the resource has been moved to a 4139 different URI, then the origin server MUST send an appropriate 3xx 4140 (Redirection) response; the user agent MAY then make its own decision 4141 regarding whether or not to redirect the request. 4143 A PUT request applied to the target resource can have side effects on 4144 other resources. For example, an article might have a URI for 4145 identifying "the current version" (a resource) that is separate from 4146 the URIs identifying each particular version (different resources 4147 that at one point shared the same state as the current version 4148 resource). A successful PUT request on "the current version" URI 4149 might therefore create a new version resource in addition to changing 4150 the state of the target resource, and might also cause links to be 4151 added between the related resources. 4153 Some origin servers support use of the Content-Range header field 4154 (Section 14.4) as a request modifier to perform a partial PUT, as 4155 described in Section 14.5. 4157 Responses to the PUT method are not cacheable. If a successful PUT 4158 request passes through a cache that has one or more stored responses 4159 for the target URI, those stored responses will be invalidated (see 4160 Section 4.4 of [CACHING]). 4162 9.3.5. DELETE 4164 The DELETE method requests that the origin server remove the 4165 association between the target resource and its current 4166 functionality. In effect, this method is similar to the "rm" command 4167 in UNIX: it expresses a deletion operation on the URI mapping of the 4168 origin server rather than an expectation that the previously 4169 associated information be deleted. 4171 If the target resource has one or more current representations, they 4172 might or might not be destroyed by the origin server, and the 4173 associated storage might or might not be reclaimed, depending 4174 entirely on the nature of the resource and its implementation by the 4175 origin server (which are beyond the scope of this specification). 4176 Likewise, other implementation aspects of a resource might need to be 4177 deactivated or archived as a result of a DELETE, such as database or 4178 gateway connections. In general, it is assumed that the origin 4179 server will only allow DELETE on resources for which it has a 4180 prescribed mechanism for accomplishing the deletion. 4182 Relatively few resources allow the DELETE method - its primary use is 4183 for remote authoring environments, where the user has some direction 4184 regarding its effect. For example, a resource that was previously 4185 created using a PUT request, or identified via the Location header 4186 field after a 201 (Created) response to a POST request, might allow a 4187 corresponding DELETE request to undo those actions. Similarly, 4188 custom user agent implementations that implement an authoring 4189 function, such as revision control clients using HTTP for remote 4190 operations, might use DELETE based on an assumption that the server's 4191 URI space has been crafted to correspond to a version repository. 4193 If a DELETE method is successfully applied, the origin server SHOULD 4194 send 4196 * a 202 (Accepted) status code if the action will likely succeed but 4197 has not yet been enacted, 4199 * a 204 (No Content) status code if the action has been enacted and 4200 no further information is to be supplied, or 4202 * a 200 (OK) status code if the action has been enacted and the 4203 response message includes a representation describing the status. 4205 Although request message framing is independent of the method used, 4206 content received in a DELETE request has no generally defined 4207 semantics, cannot alter the meaning or target of the request, and 4208 might lead some implementations to reject the request and close the 4209 connection because of its potential as a request smuggling attack 4210 (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content 4211 in a DELETE request unless it is made directly to an origin server 4212 that has previously indicated, in or out of band, that such a request 4213 has a purpose and will be adequately supported. An origin server 4214 SHOULD NOT rely on private agreements to receive content, since 4215 participants in HTTP communication are often unaware of 4216 intermediaries along the request chain. 4218 Responses to the DELETE method are not cacheable. If a successful 4219 DELETE request passes through a cache that has one or more stored 4220 responses for the target URI, those stored responses will be 4221 invalidated (see Section 4.4 of [CACHING]). 4223 9.3.6. CONNECT 4225 The CONNECT method requests that the recipient establish a tunnel to 4226 the destination origin server identified by the request target and, 4227 if successful, thereafter restrict its behavior to blind forwarding 4228 of data, in both directions, until the tunnel is closed. Tunnels are 4229 commonly used to create an end-to-end virtual connection, through one 4230 or more proxies, which can then be secured using TLS (Transport Layer 4231 Security, [TLS13]). 4233 CONNECT uses a special form of request target, unique to this method, 4234 consisting of only the host and port number of the tunnel 4235 destination, separated by a colon. There is no default port; a 4236 client MUST send the port number even if the CONNECT request is based 4237 on a URI reference that contains an authority component with an 4238 elided port (Section 4.1). For example, 4240 CONNECT server.example.com:80 HTTP/1.1 4241 Host: server.example.com 4243 A server MUST reject a CONNECT request that targets an empty or 4244 invalid port number, typically by responding with a 400 (Bad Request) 4245 status code. 4247 Because CONNECT changes the request/response nature of an HTTP 4248 connection, specific HTTP versions might have different ways of 4249 mapping its semantics into the protocol's wire format. 4251 CONNECT is intended for use in requests to a proxy. The recipient 4252 can establish a tunnel either by directly connecting to the server 4253 identified by the request target or, if configured to use another 4254 proxy, by forwarding the CONNECT request to the next inbound proxy. 4255 An origin server MAY accept a CONNECT request, but most origin 4256 servers do not implement CONNECT. 4258 Any 2xx (Successful) response indicates that the sender (and all 4259 inbound proxies) will switch to tunnel mode immediately after the 4260 response header section; data received after that header section is 4261 from the server identified by the request target. Any response other 4262 than a successful response indicates that the tunnel has not yet been 4263 formed. 4265 A tunnel is closed when a tunnel intermediary detects that either 4266 side has closed its connection: the intermediary MUST attempt to send 4267 any outstanding data that came from the closed side to the other 4268 side, close both connections, and then discard any remaining data 4269 left undelivered. 4271 Proxy authentication might be used to establish the authority to 4272 create a tunnel. For example, 4274 CONNECT server.example.com:443 HTTP/1.1 4275 Host: server.example.com:443 4276 Proxy-Authorization: basic aGVsbG86d29ybGQ= 4278 There are significant risks in establishing a tunnel to arbitrary 4279 servers, particularly when the destination is a well-known or 4280 reserved TCP port that is not intended for Web traffic. For example, 4281 a CONNECT to "example.com:25" would suggest that the proxy connect to 4282 the reserved port for SMTP traffic; if allowed, that could trick the 4283 proxy into relaying spam email. Proxies that support CONNECT SHOULD 4284 restrict its use to a limited set of known ports or a configurable 4285 list of safe request targets. 4287 A server MUST NOT send any Transfer-Encoding or Content-Length header 4288 fields in a 2xx (Successful) response to CONNECT. A client MUST 4289 ignore any Content-Length or Transfer-Encoding header fields received 4290 in a successful response to CONNECT. 4292 A CONNECT request message does not have content. The interpretation 4293 of data sent after the header section of the CONNECT request message 4294 is specific to the version of HTTP in use. 4296 Responses to the CONNECT method are not cacheable. 4298 9.3.7. OPTIONS 4300 The OPTIONS method requests information about the communication 4301 options available for the target resource, at either the origin 4302 server or an intervening intermediary. This method allows a client 4303 to determine the options and/or requirements associated with a 4304 resource, or the capabilities of a server, without implying a 4305 resource action. 4307 An OPTIONS request with an asterisk ("*") as the request target 4308 (Section 7.1) applies to the server in general rather than to a 4309 specific resource. Since a server's communication options typically 4310 depend on the resource, the "*" request is only useful as a "ping" or 4311 "no-op" type of method; it does nothing beyond allowing the client to 4312 test the capabilities of the server. For example, this can be used 4313 to test a proxy for HTTP/1.1 conformance (or lack thereof). 4315 If the request target is not an asterisk, the OPTIONS request applies 4316 to the options that are available when communicating with the target 4317 resource. 4319 A server generating a successful response to OPTIONS SHOULD send any 4320 header that might indicate optional features implemented by the 4321 server and applicable to the target resource (e.g., Allow), including 4322 potential extensions not defined by this specification. The response 4323 content, if any, might also describe the communication options in a 4324 machine or human-readable representation. A standard format for such 4325 a representation is not defined by this specification, but might be 4326 defined by future extensions to HTTP. 4328 A client MAY send a Max-Forwards header field in an OPTIONS request 4329 to target a specific recipient in the request chain (see 4330 Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header 4331 field while forwarding a request unless that request was received 4332 with a Max-Forwards field. 4334 A client that generates an OPTIONS request containing content MUST 4335 send a valid Content-Type header field describing the representation 4336 media type. Note that this specification does not define any use for 4337 such content. 4339 Responses to the OPTIONS method are not cacheable. 4341 9.3.8. TRACE 4343 The TRACE method requests a remote, application-level loop-back of 4344 the request message. The final recipient of the request SHOULD 4345 reflect the message received, excluding some fields described below, 4346 back to the client as the content of a 200 (OK) response. The 4347 "message/http" (Section 10.1 of [HTTP/1.1]) format is one way to do 4348 so. The final recipient is either the origin server or the first 4349 server to receive a Max-Forwards value of zero (0) in the request 4350 (Section 7.6.2). 4352 A client MUST NOT generate fields in a TRACE request containing 4353 sensitive data that might be disclosed by the response. For example, 4354 it would be foolish for a user agent to send stored user credentials 4355 (Section 11) or cookies [COOKIE] in a TRACE request. The final 4356 recipient of the request SHOULD exclude any request fields that are 4357 likely to contain sensitive data when that recipient generates the 4358 response content. 4360 TRACE allows the client to see what is being received at the other 4361 end of the request chain and use that data for testing or diagnostic 4362 information. The value of the Via header field (Section 7.6.3) is of 4363 particular interest, since it acts as a trace of the request chain. 4364 Use of the Max-Forwards header field allows the client to limit the 4365 length of the request chain, which is useful for testing a chain of 4366 proxies forwarding messages in an infinite loop. 4368 A client MUST NOT send content in a TRACE request. 4370 Responses to the TRACE method are not cacheable. 4372 10. Message Context 4374 10.1. Request Context Fields 4376 The request header fields below provide additional information about 4377 the request context, including information about the user, user 4378 agent, and resource behind the request. 4380 10.1.1. Expect 4382 The "Expect" header field in a request indicates a certain set of 4383 behaviors (expectations) that need to be supported by the server in 4384 order to properly handle this request. 4386 Expect = #expectation 4387 expectation = token [ "=" ( token / quoted-string ) parameters ] 4389 The Expect field value is case-insensitive. 4391 The only expectation defined by this specification is "100-continue" 4392 (with no defined parameters). 4394 A server that receives an Expect field value containing a member 4395 other than 100-continue MAY respond with a 417 (Expectation Failed) 4396 status code to indicate that the unexpected expectation cannot be 4397 met. 4399 A _100-continue_ expectation informs recipients that the client is 4400 about to send (presumably large) content in this request and wishes 4401 to receive a 100 (Continue) interim response if the method, target 4402 URI, and header fields are not sufficient to cause an immediate 4403 success, redirect, or error response. This allows the client to wait 4404 for an indication that it is worthwhile to send the content before 4405 actually doing so, which can improve efficiency when the data is huge 4406 or when the client anticipates that an error is likely (e.g., when 4407 sending a state-changing method, for the first time, without 4408 previously verified authentication credentials). 4410 For example, a request that begins with 4411 PUT /somewhere/fun HTTP/1.1 4412 Host: origin.example.com 4413 Content-Type: video/h264 4414 Content-Length: 1234567890987 4415 Expect: 100-continue 4417 allows the origin server to immediately respond with an error 4418 message, such as 401 (Unauthorized) or 405 (Method Not Allowed), 4419 before the client starts filling the pipes with an unnecessary data 4420 transfer. 4422 Requirements for clients: 4424 * A client MUST NOT generate a 100-continue expectation in a request 4425 that does not include content. 4427 * A client that will wait for a 100 (Continue) response before 4428 sending the request content MUST send an Expect header field 4429 containing a 100-continue expectation. 4431 * A client that sends a 100-continue expectation is not required to 4432 wait for any specific length of time; such a client MAY proceed to 4433 send the content even if it has not yet received a response. 4434 Furthermore, since 100 (Continue) responses cannot be sent through 4435 an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an 4436 indefinite period before sending the content. 4438 * A client that receives a 417 (Expectation Failed) status code in 4439 response to a request containing a 100-continue expectation SHOULD 4440 repeat that request without a 100-continue expectation, since the 4441 417 response merely indicates that the response chain does not 4442 support expectations (e.g., it passes through an HTTP/1.0 server). 4444 Requirements for servers: 4446 * A server that receives a 100-continue expectation in an HTTP/1.0 4447 request MUST ignore that expectation. 4449 * A server MAY omit sending a 100 (Continue) response if it has 4450 already received some or all of the content for the corresponding 4451 request, or if the framing indicates that there is no content. 4453 * A server that sends a 100 (Continue) response MUST ultimately send 4454 a final status code, once it receives and processes the request 4455 content, unless the connection is closed prematurely. 4457 * A server that responds with a final status code before reading the 4458 entire request content SHOULD indicate whether it intends to close 4459 the connection (e.g., see Section 9.6 of [HTTP/1.1]) or continue 4460 reading the request content. 4462 An origin server MUST, upon receiving an HTTP/1.1 (or later) request 4463 that has a method, target URI, and complete header section that 4464 contains a 100-continue expectation and an indication that request 4465 content will follow, either send an immediate response with a final 4466 status code, if that status can be determined by examining just the 4467 method, target URI, and header fields, or send an immediate 100 4468 (Continue) response to encourage the client to send the request 4469 content. The origin server MUST NOT wait for the content before 4470 sending the 100 (Continue) response. 4472 A proxy MUST, upon receiving an HTTP/1.1 (or later) request that has 4473 a method, target URI, and complete header section that contains a 4474 100-continue expectation and indicates a request content will follow, 4475 either send an immediate response with a final status code, if that 4476 status can be determined by examining just the method, target URI, 4477 and header fields, or begin forwarding the request toward the origin 4478 server by sending a corresponding request-line and header section to 4479 the next inbound server. If the proxy believes (from configuration 4480 or past interaction) that the next inbound server only supports 4481 HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response 4482 to encourage the client to begin sending the content. 4484 10.1.2. From 4486 The "From" header field contains an Internet email address for a 4487 human user who controls the requesting user agent. The address ought 4488 to be machine-usable, as defined by "mailbox" in Section 3.4 of 4489 [RFC5322]: 4491 From = mailbox 4493 mailbox = 4495 An example is: 4497 From: webmaster@example.org 4499 The From header field is rarely sent by non-robotic user agents. A 4500 user agent SHOULD NOT send a From header field without explicit 4501 configuration by the user, since that might conflict with the user's 4502 privacy interests or their site's security policy. 4504 A robotic user agent SHOULD send a valid From header field so that 4505 the person responsible for running the robot can be contacted if 4506 problems occur on servers, such as if the robot is sending excessive, 4507 unwanted, or invalid requests. 4509 A server SHOULD NOT use the From header field for access control or 4510 authentication, since its value is expected to be visible to anyone 4511 receiving or observing the request and is often recorded within 4512 logfiles and error reports without any expectation of privacy. 4514 10.1.3. Referer 4516 The "Referer" [sic] header field allows the user agent to specify a 4517 URI reference for the resource from which the target URI was obtained 4518 (i.e., the "referrer", though the field name is misspelled). A user 4519 agent MUST NOT include the fragment and userinfo components of the 4520 URI reference [URI], if any, when generating the Referer field value. 4522 Referer = absolute-URI / partial-URI 4524 The field value is either an absolute-URI or a partial-URI. In the 4525 latter case (Section 4), the referenced URI is relative to the target 4526 URI ([URI], Section 5). 4528 The Referer header field allows servers to generate back-links to 4529 other resources for simple analytics, logging, optimized caching, 4530 etc. It also allows obsolete or mistyped links to be found for 4531 maintenance. Some servers use the Referer header field as a means of 4532 denying links from other sites (so-called "deep linking") or 4533 restricting cross-site request forgery (CSRF), but not all requests 4534 contain it. 4536 Example: 4538 Referer: http://www.example.org/hypertext/Overview.html 4540 If the target URI was obtained from a source that does not have its 4541 own URI (e.g., input from the user keyboard, or an entry within the 4542 user's bookmarks/favorites), the user agent MUST either exclude the 4543 Referer header field or send it with a value of "about:blank". 4545 The Referer header field value need not convey the full URI of the 4546 referring resource; a user agent MAY truncate parts other than the 4547 referring origin. 4549 The Referer header field has the potential to reveal information 4550 about the request context or browsing history of the user, which is a 4551 privacy concern if the referring resource's identifier reveals 4552 personal information (such as an account name) or a resource that is 4553 supposed to be confidential (such as behind a firewall or internal to 4554 a secured service). Most general-purpose user agents do not send the 4555 Referer header field when the referring resource is a local "file" or 4556 "data" URI. A user agent SHOULD NOT send a Referer header field if 4557 the referring resource was accessed with a secure protocol and the 4558 request target has an origin differing from that of the referring 4559 resource, unless the referring resource explicitly allows Referer to 4560 be sent. A user agent MUST NOT send a Referer header field in an 4561 unsecured HTTP request if the referring resource was accessed with a 4562 secure protocol. See Section 17.9 for additional security 4563 considerations. 4565 Some intermediaries have been known to indiscriminately remove 4566 Referer header fields from outgoing requests. This has the 4567 unfortunate side effect of interfering with protection against CSRF 4568 attacks, which can be far more harmful to their users. 4569 Intermediaries and user agent extensions that wish to limit 4570 information disclosure in Referer ought to restrict their changes to 4571 specific edits, such as replacing internal domain names with 4572 pseudonyms or truncating the query and/or path components. An 4573 intermediary SHOULD NOT modify or delete the Referer header field 4574 when the field value shares the same scheme and host as the target 4575 URI. 4577 10.1.4. TE 4579 The "TE" header field describes capabilities of the client with 4580 regard to transfer encodings and trailer sections. 4582 A TE field with a "trailers" member sent in a request indicates that 4583 the client will not discard trailer fields, as described in 4584 Section 6.5. 4586 TE is also used within HTTP/1.1 to advise servers about what transfer 4587 codings the client is able to accept in a response. As of 4588 publication, only HTTP/1.1 uses transfer codings (see Section 7 of 4589 [HTTP/1.1]). 4591 The TE field value consists of a list of tokens, each allowing for 4592 optional parameters (except for the special case "trailers"). 4594 TE = #t-codings 4595 t-codings = "trailers" / ( transfer-coding [ weight ] ) 4596 transfer-coding = token *( OWS ";" OWS transfer-parameter ) 4597 transfer-parameter = token BWS "=" BWS ( token / quoted-string ) 4599 A sender of TE MUST also send a "TE" connection option within the 4600 Connection header field (Section 7.6.1) to inform intermediaries not 4601 to forward this field. 4603 10.1.5. Trailer 4605 The "Trailer" header field provides a list of field names that the 4606 sender anticipates sending as trailer fields within that message. 4607 This allows a recipient to prepare for receipt of the indicated 4608 metadata before it starts processing the content. 4610 Trailer = #field-name 4612 For example, a sender might indicate that a message integrity check 4613 will be computed as the content is being streamed and provide the 4614 final signature as a trailer field. This allows a recipient to 4615 perform the same check on the fly as it receives the content. 4617 Because the Trailer field is not removed by intermediaries, it can 4618 also be used by downstream recipients to discover when a trailer 4619 field has been removed from a message. 4621 A sender that intends to generate one or more trailer fields in a 4622 message SHOULD generate a Trailer header field in the header section 4623 of that message to indicate which fields might be present in the 4624 trailers. 4626 10.1.6. User-Agent 4628 The "User-Agent" header field contains information about the user 4629 agent originating the request, which is often used by servers to help 4630 identify the scope of reported interoperability problems, to work 4631 around or tailor responses to avoid particular user agent 4632 limitations, and for analytics regarding browser or operating system 4633 use. A user agent SHOULD send a User-Agent header field in each 4634 request unless specifically configured not to do so. 4636 User-Agent = product *( RWS ( product / comment ) ) 4638 The User-Agent field value consists of one or more product 4639 identifiers, each followed by zero or more comments (Section 5.6.5), 4640 which together identify the user agent software and its significant 4641 subproducts. By convention, the product identifiers are listed in 4642 decreasing order of their significance for identifying the user agent 4643 software. Each product identifier consists of a name and optional 4644 version. 4646 product = token ["/" product-version] 4647 product-version = token 4649 A sender SHOULD limit generated product identifiers to what is 4650 necessary to identify the product; a sender MUST NOT generate 4651 advertising or other nonessential information within the product 4652 identifier. A sender SHOULD NOT generate information in 4653 product-version that is not a version identifier (i.e., successive 4654 versions of the same product name ought to differ only in the 4655 product-version portion of the product identifier). 4657 Example: 4659 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 4661 A user agent SHOULD NOT generate a User-Agent header field containing 4662 needlessly fine-grained detail and SHOULD limit the addition of 4663 subproducts by third parties. Overly long and detailed User-Agent 4664 field values increase request latency and the risk of a user being 4665 identified against their wishes ("fingerprinting"). 4667 Likewise, implementations are encouraged not to use the product 4668 tokens of other implementations in order to declare compatibility 4669 with them, as this circumvents the purpose of the field. If a user 4670 agent masquerades as a different user agent, recipients can assume 4671 that the user intentionally desires to see responses tailored for 4672 that identified user agent, even if they might not work as well for 4673 the actual user agent being used. 4675 10.2. Response Context Fields 4677 The response header fields below provide additional information about 4678 the response, beyond what is implied by the status code, including 4679 information about the server, about the target resource, or about 4680 related resources. 4682 10.2.1. Allow 4684 The "Allow" header field lists the set of methods advertised as 4685 supported by the target resource. The purpose of this field is 4686 strictly to inform the recipient of valid request methods associated 4687 with the resource. 4689 Allow = #method 4691 Example of use: 4693 Allow: GET, HEAD, PUT 4694 The actual set of allowed methods is defined by the origin server at 4695 the time of each request. An origin server MUST generate an Allow 4696 header field in a 405 (Method Not Allowed) response and MAY do so in 4697 any other response. An empty Allow field value indicates that the 4698 resource allows no methods, which might occur in a 405 response if 4699 the resource has been temporarily disabled by configuration. 4701 A proxy MUST NOT modify the Allow header field - it does not need to 4702 understand all of the indicated methods in order to handle them 4703 according to the generic message handling rules. 4705 10.2.2. Date 4707 The "Date" header field represents the date and time at which the 4708 message was originated, having the same semantics as the Origination 4709 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 4710 field value is an HTTP-date, as defined in Section 5.6.7. 4712 Date = HTTP-date 4714 An example is 4716 Date: Tue, 15 Nov 1994 08:12:31 GMT 4718 A sender that generates a Date header field SHOULD generate its field 4719 value as the best available approximation of the date and time of 4720 message generation. In theory, the date ought to represent the 4721 moment just before generating the message content. In practice, a 4722 sender can generate the date value at any time during message 4723 origination. 4725 An origin server MUST NOT send a Date header field if it does not 4726 have a clock capable of providing a reasonable approximation of the 4727 current instant in Coordinated Universal Time. An origin server MAY 4728 send a Date header field if the response is in the 1xx 4729 (Informational) or 5xx (Server Error) class of status codes. An 4730 origin server MUST send a Date header field in all other cases. 4732 A recipient with a clock that receives a response message without a 4733 Date header field MUST record the time it was received and append a 4734 corresponding Date header field to the message's header section if it 4735 is cached or forwarded downstream. 4737 A recipient with a clock that receives a response with an invalid 4738 Date header field value MAY replace that value with the time that 4739 response was received. 4741 A user agent MAY send a Date header field in a request, though 4742 generally will not do so unless it is believed to convey useful 4743 information to the server. For example, custom applications of HTTP 4744 might convey a Date if the server is expected to adjust its 4745 interpretation of the user's request based on differences between the 4746 user agent and server clocks. 4748 10.2.3. Location 4750 The "Location" header field is used in some responses to refer to a 4751 specific resource in relation to the response. The type of 4752 relationship is defined by the combination of request method and 4753 status code semantics. 4755 Location = URI-reference 4757 The field value consists of a single URI-reference. When it has the 4758 form of a relative reference ([URI], Section 4.2), the final value is 4759 computed by resolving it against the target URI ([URI], Section 5). 4761 For 201 (Created) responses, the Location value refers to the primary 4762 resource created by the request. For 3xx (Redirection) responses, 4763 the Location value refers to the preferred target resource for 4764 automatically redirecting the request. 4766 If the Location value provided in a 3xx (Redirection) response does 4767 not have a fragment component, a user agent MUST process the 4768 redirection as if the value inherits the fragment component of the 4769 URI reference used to generate the target URI (i.e., the redirection 4770 inherits the original reference's fragment, if any). 4772 For example, a GET request generated for the URI reference 4773 "http://www.example.org/~tim" might result in a 303 (See Other) 4774 response containing the header field: 4776 Location: /People.html#tim 4778 which suggests that the user agent redirect to 4779 "http://www.example.org/People.html#tim" 4781 Likewise, a GET request generated for the URI reference 4782 "http://www.example.org/index.html#larry" might result in a 301 4783 (Moved Permanently) response containing the header field: 4785 Location: http://www.example.net/index.html 4786 which suggests that the user agent redirect to 4787 "http://www.example.net/index.html#larry", preserving the original 4788 fragment identifier. 4790 There are circumstances in which a fragment identifier in a Location 4791 value would not be appropriate. For example, the Location header 4792 field in a 201 (Created) response is supposed to provide a URI that 4793 is specific to the created resource. 4795 | *Note:* Some recipients attempt to recover from Location header 4796 | fields that are not valid URI references. This specification 4797 | does not mandate or define such processing, but does allow it 4798 | for the sake of robustness. A Location field value cannot 4799 | allow a list of members because the comma list separator is a 4800 | valid data character within a URI-reference. If an invalid 4801 | message is sent with multiple Location field lines, a recipient 4802 | along the path might combine those field lines into one value. 4803 | Recovery of a valid Location field value from that situation is 4804 | difficult and not interoperable across implementations. 4806 | *Note:* The Content-Location header field (Section 8.7) differs 4807 | from Location in that the Content-Location refers to the most 4808 | specific resource corresponding to the enclosed representation. 4809 | It is therefore possible for a response to contain both the 4810 | Location and Content-Location header fields. 4812 10.2.4. Retry-After 4814 Servers send the "Retry-After" header field to indicate how long the 4815 user agent ought to wait before making a follow-up request. When 4816 sent with a 503 (Service Unavailable) response, Retry-After indicates 4817 how long the service is expected to be unavailable to the client. 4818 When sent with any 3xx (Redirection) response, Retry-After indicates 4819 the minimum time that the user agent is asked to wait before issuing 4820 the redirected request. 4822 The Retry-After field value can be either an HTTP-date or a number of 4823 seconds to delay after receiving the response. 4825 Retry-After = HTTP-date / delay-seconds 4827 A delay-seconds value is a non-negative decimal integer, representing 4828 time in seconds. 4830 delay-seconds = 1*DIGIT 4832 Two examples of its use are 4833 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 4834 Retry-After: 120 4836 In the latter example, the delay is 2 minutes. 4838 10.2.5. Server 4840 The "Server" header field contains information about the software 4841 used by the origin server to handle the request, which is often used 4842 by clients to help identify the scope of reported interoperability 4843 problems, to work around or tailor requests to avoid particular 4844 server limitations, and for analytics regarding server or operating 4845 system use. An origin server MAY generate a Server header field in 4846 its responses. 4848 Server = product *( RWS ( product / comment ) ) 4850 The Server header field value consists of one or more product 4851 identifiers, each followed by zero or more comments (Section 5.6.5), 4852 which together identify the origin server software and its 4853 significant subproducts. By convention, the product identifiers are 4854 listed in decreasing order of their significance for identifying the 4855 origin server software. Each product identifier consists of a name 4856 and optional version, as defined in Section 10.1.6. 4858 Example: 4860 Server: CERN/3.0 libwww/2.17 4862 An origin server SHOULD NOT generate a Server header field containing 4863 needlessly fine-grained detail and SHOULD limit the addition of 4864 subproducts by third parties. Overly long and detailed Server field 4865 values increase response latency and potentially reveal internal 4866 implementation details that might make it (slightly) easier for 4867 attackers to find and exploit known security holes. 4869 11. HTTP Authentication 4871 11.1. Authentication Scheme 4873 HTTP provides a general framework for access control and 4874 authentication, via an extensible set of challenge-response 4875 authentication schemes, which can be used by a server to challenge a 4876 client request and by a client to provide authentication information. 4877 It uses a case-insensitive token to identify the authentication 4878 scheme 4880 auth-scheme = token 4882 Aside from the general framework, this document does not specify any 4883 authentication schemes. New and existing authentication schemes are 4884 specified independently and ought to be registered within the 4885 "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". 4886 For example, the "basic" and "digest" authentication schemes are 4887 defined by RFC 7617 and RFC 7616, respectively. 4889 11.2. Authentication Parameters 4891 The authentication scheme is followed by additional information 4892 necessary for achieving authentication via that scheme as either a 4893 comma-separated list of parameters or a single sequence of characters 4894 capable of holding base64-encoded information. 4896 token68 = 1*( ALPHA / DIGIT / 4897 "-" / "." / "_" / "~" / "+" / "/" ) *"=" 4899 The token68 syntax allows the 66 unreserved URI characters ([URI]), 4900 plus a few others, so that it can hold a base64, base64url (URL and 4901 filename safe alphabet), base32, or base16 (hex) encoding, with or 4902 without padding, but excluding whitespace ([RFC4648]). 4904 Authentication parameters are name=value pairs, where the name token 4905 is matched case-insensitively and each parameter name MUST only occur 4906 once per challenge. 4908 auth-param = token BWS "=" BWS ( token / quoted-string ) 4910 Parameter values can be expressed either as "token" or as "quoted- 4911 string" (Section 5.6). Authentication scheme definitions need to 4912 accept both notations, both for senders and recipients, to allow 4913 recipients to use generic parsing components regardless of the 4914 authentication scheme. 4916 For backwards compatibility, authentication scheme definitions can 4917 restrict the format for senders to one of the two variants. This can 4918 be important when it is known that deployed implementations will fail 4919 when encountering one of the two formats. 4921 11.3. Challenge and Response 4923 A 401 (Unauthorized) response message is used by an origin server to 4924 challenge the authorization of a user agent, including a 4925 WWW-Authenticate header field containing at least one challenge 4926 applicable to the requested resource. 4928 A 407 (Proxy Authentication Required) response message is used by a 4929 proxy to challenge the authorization of a client, including a 4930 Proxy-Authenticate header field containing at least one challenge 4931 applicable to the proxy for the requested resource. 4933 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 4935 | *Note:* Many clients fail to parse a challenge that contains an 4936 | unknown scheme. A workaround for this problem is to list well- 4937 | supported schemes (such as "basic") first. 4939 A user agent that wishes to authenticate itself with an origin server 4940 - usually, but not necessarily, after receiving a 401 (Unauthorized) 4941 - can do so by including an Authorization header field with the 4942 request. 4944 A client that wishes to authenticate itself with a proxy - usually, 4945 but not necessarily, after receiving a 407 (Proxy Authentication 4946 Required) - can do so by including a Proxy-Authorization header field 4947 with the request. 4949 11.4. Credentials 4951 Both the Authorization field value and the Proxy-Authorization field 4952 value contain the client's credentials for the realm of the resource 4953 being requested, based upon a challenge received in a response 4954 (possibly at some point in the past). When creating their values, 4955 the user agent ought to do so by selecting the challenge with what it 4956 considers to be the most secure auth-scheme that it understands, 4957 obtaining credentials from the user as appropriate. Transmission of 4958 credentials within header field values implies significant security 4959 considerations regarding the confidentiality of the underlying 4960 connection, as described in Section 17.16.1. 4962 credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 4964 Upon receipt of a request for a protected resource that omits 4965 credentials, contains invalid credentials (e.g., a bad password) or 4966 partial credentials (e.g., when the authentication scheme requires 4967 more than one round trip), an origin server SHOULD send a 401 4968 (Unauthorized) response that contains a WWW-Authenticate header field 4969 with at least one (possibly new) challenge applicable to the 4970 requested resource. 4972 Likewise, upon receipt of a request that omits proxy credentials or 4973 contains invalid or partial proxy credentials, a proxy that requires 4974 authentication SHOULD generate a 407 (Proxy Authentication Required) 4975 response that contains a Proxy-Authenticate header field with at 4976 least one (possibly new) challenge applicable to the proxy. 4978 A server that receives valid credentials that are not adequate to 4979 gain access ought to respond with the 403 (Forbidden) status code 4980 (Section 15.5.4). 4982 HTTP does not restrict applications to this simple challenge-response 4983 framework for access authentication. Additional mechanisms can be 4984 used, such as authentication at the transport level or via message 4985 encapsulation, and with additional header fields specifying 4986 authentication information. However, such additional mechanisms are 4987 not defined by this specification. 4989 Note that various custom mechanisms for user authentication use the 4990 Set-Cookie and Cookie header fields, defined in [COOKIE], for passing 4991 tokens related to authentication. 4993 11.5. Establishing a Protection Space (Realm) 4995 The _realm_ authentication parameter is reserved for use by 4996 authentication schemes that wish to indicate a scope of protection. 4998 A _protection space_ is defined by the origin (see Section 4.3.1) of 4999 the server being accessed, in combination with the realm value if 5000 present. These realms allow the protected resources on a server to 5001 be partitioned into a set of protection spaces, each with its own 5002 authentication scheme and/or authorization database. The realm value 5003 is a string, generally assigned by the origin server, that can have 5004 additional semantics specific to the authentication scheme. Note 5005 that a response can have multiple challenges with the same auth- 5006 scheme but with different realms. 5008 The protection space determines the domain over which credentials can 5009 be automatically applied. If a prior request has been authorized, 5010 the user agent MAY reuse the same credentials for all other requests 5011 within that protection space for a period of time determined by the 5012 authentication scheme, parameters, and/or user preferences (such as a 5013 configurable inactivity timeout). 5015 The extent of a protection space, and therefore the requests to which 5016 credentials might be automatically applied, is not necessarily known 5017 to clients without additional information. An authentication scheme 5018 might define parameters that describe the extent of a protection 5019 space. Unless specifically allowed by the authentication scheme, a 5020 single protection space cannot extend outside the scope of its 5021 server. 5023 For historical reasons, a sender MUST only generate the quoted-string 5024 syntax. Recipients might have to support both token and quoted- 5025 string syntax for maximum interoperability with existing clients that 5026 have been accepting both notations for a long time. 5028 11.6. Authenticating Users to Origin Servers 5030 11.6.1. WWW-Authenticate 5032 The "WWW-Authenticate" response header field indicates the 5033 authentication scheme(s) and parameters applicable to the target 5034 resource. 5036 WWW-Authenticate = #challenge 5038 A server generating a 401 (Unauthorized) response MUST send a WWW- 5039 Authenticate header field containing at least one challenge. A 5040 server MAY generate a WWW-Authenticate header field in other response 5041 messages to indicate that supplying credentials (or different 5042 credentials) might affect the response. 5044 A proxy forwarding a response MUST NOT modify any WWW-Authenticate 5045 header fields in that response. 5047 User agents are advised to take special care in parsing the field 5048 value, as it might contain more than one challenge, and each 5049 challenge can contain a comma-separated list of authentication 5050 parameters. Furthermore, the header field itself can occur multiple 5051 times. 5053 For instance: 5055 WWW-Authenticate: Basic realm="simple", Newauth realm="apps", 5056 type=1, title="Login to \"apps\"" 5058 This header field contains two challenges; one for the "Basic" scheme 5059 with a realm value of "simple", and another for the "Newauth" scheme 5060 with a realm value of "apps", and two additional parameters "type" 5061 and "title". 5063 Some user agents do not recognise this form, however. As a result, 5064 sending a WWW-Authenticate field value with more than one member on 5065 the same field line might not be interoperable. 5067 | *Note:* The challenge grammar production uses the list syntax 5068 | as well. Therefore, a sequence of comma, whitespace, and comma 5069 | can be considered either as applying to the preceding 5070 | challenge, or to be an empty entry in the list of challenges. 5071 | In practice, this ambiguity does not affect the semantics of 5072 | the header field value and thus is harmless. 5074 11.6.2. Authorization 5076 The "Authorization" header field allows a user agent to authenticate 5077 itself with an origin server - usually, but not necessarily, after 5078 receiving a 401 (Unauthorized) response. Its value consists of 5079 credentials containing the authentication information of the user 5080 agent for the realm of the resource being requested. 5082 Authorization = credentials 5084 If a request is authenticated and a realm specified, the same 5085 credentials are presumed to be valid for all other requests within 5086 this realm (assuming that the authentication scheme itself does not 5087 require otherwise, such as credentials that vary according to a 5088 challenge value or using synchronized clocks). 5090 A proxy forwarding a request MUST NOT modify any Authorization header 5091 fields in that request. See Section 3.5 of [CACHING] for details of 5092 and requirements pertaining to handling of the Authorization header 5093 field by HTTP caches. 5095 11.6.3. Authentication-Info 5097 HTTP authentication schemes can use the Authentication-Info response 5098 field to communicate information after the client's authentication 5099 credentials have been accepted. This information can include a 5100 finalization message from the server (e.g., it can contain the server 5101 authentication). 5103 The field value is a list of parameters (name/value pairs), using the 5104 "auth-param" syntax defined in Section 11.3. This specification only 5105 describes the generic format; authentication schemes using 5106 Authentication-Info will define the individual parameters. The 5107 "Digest" Authentication Scheme, for instance, defines multiple 5108 parameters in Section 3.5 of [RFC7616]. 5110 Authentication-Info = #auth-param 5112 The Authentication-Info field can be used in any HTTP response, 5113 independently of request method and status code. Its semantics are 5114 defined by the authentication scheme indicated by the Authorization 5115 header field (Section 11.6.2) of the corresponding request. 5117 A proxy forwarding a response is not allowed to modify the field 5118 value in any way. 5120 Authentication-Info can be sent as a trailer field (Section 6.5) when 5121 the authentication scheme explicitly allows this. 5123 11.7. Authenticating Clients to Proxies 5125 11.7.1. Proxy-Authenticate 5127 The "Proxy-Authenticate" header field consists of at least one 5128 challenge that indicates the authentication scheme(s) and parameters 5129 applicable to the proxy for this request. A proxy MUST send at least 5130 one Proxy-Authenticate header field in each 407 (Proxy Authentication 5131 Required) response that it generates. 5133 Proxy-Authenticate = #challenge 5135 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 5136 only to the next outbound client on the response chain. This is 5137 because only the client that chose a given proxy is likely to have 5138 the credentials necessary for authentication. However, when multiple 5139 proxies are used within the same administrative domain, such as 5140 office and regional caching proxies within a large corporate network, 5141 it is common for credentials to be generated by the user agent and 5142 passed through the hierarchy until consumed. Hence, in such a 5143 configuration, it will appear as if Proxy-Authenticate is being 5144 forwarded because each proxy will send the same challenge set. 5146 Note that the parsing considerations for WWW-Authenticate apply to 5147 this header field as well; see Section 11.6.1 for details. 5149 11.7.2. Proxy-Authorization 5151 The "Proxy-Authorization" header field allows the client to identify 5152 itself (or its user) to a proxy that requires authentication. Its 5153 value consists of credentials containing the authentication 5154 information of the client for the proxy and/or realm of the resource 5155 being requested. 5157 Proxy-Authorization = credentials 5159 Unlike Authorization, the Proxy-Authorization header field applies 5160 only to the next inbound proxy that demanded authentication using the 5161 Proxy-Authenticate header field. When multiple proxies are used in a 5162 chain, the Proxy-Authorization header field is consumed by the first 5163 inbound proxy that was expecting to receive credentials. A proxy MAY 5164 relay the credentials from the client request to the next proxy if 5165 that is the mechanism by which the proxies cooperatively authenticate 5166 a given request. 5168 11.7.3. Proxy-Authentication-Info 5170 The Proxy-Authentication-Info response header field is equivalent to 5171 Authentication-Info, except that it applies to proxy authentication 5172 (Section 11.3) and its semantics are defined by the authentication 5173 scheme indicated by the Proxy-Authorization header field 5174 (Section 11.7.2) of the corresponding request: 5176 Proxy-Authentication-Info = #auth-param 5178 However, unlike Authentication-Info, the Proxy-Authentication-Info 5179 header field applies only to the next outbound client on the response 5180 chain. This is because only the client that chose a given proxy is 5181 likely to have the credentials necessary for authentication. 5182 However, when multiple proxies are used within the same 5183 administrative domain, such as office and regional caching proxies 5184 within a large corporate network, it is common for credentials to be 5185 generated by the user agent and passed through the hierarchy until 5186 consumed. Hence, in such a configuration, it will appear as if 5187 Proxy-Authentication-Info is being forwarded because each proxy will 5188 send the same field value. 5190 12. Content Negotiation 5192 When responses convey content, whether indicating a success or an 5193 error, the origin server often has different ways of representing 5194 that information; for example, in different formats, languages, or 5195 encodings. Likewise, different users or user agents might have 5196 differing capabilities, characteristics, or preferences that could 5197 influence which representation, among those available, would be best 5198 to deliver. For this reason, HTTP provides mechanisms for content 5199 negotiation. 5201 This specification defines three patterns of content negotiation that 5202 can be made visible within the protocol: "proactive" negotiation, 5203 where the server selects the representation based upon the user 5204 agent's stated preferences, "reactive" negotiation, where the server 5205 provides a list of representations for the user agent to choose from, 5206 and "request content" negotiation, where the user agent selects the 5207 representation for a future request based upon the server's stated 5208 preferences in past responses. 5210 Other patterns of content negotiation include "conditional content", 5211 where the representation consists of multiple parts that are 5212 selectively rendered based on user agent parameters, "active 5213 content", where the representation contains a script that makes 5214 additional (more specific) requests based on the user agent 5215 characteristics, and "Transparent Content Negotiation" ([RFC2295]), 5216 where content selection is performed by an intermediary. These 5217 patterns are not mutually exclusive, and each has trade-offs in 5218 applicability and practicality. 5220 Note that, in all cases, HTTP is not aware of the resource semantics. 5221 The consistency with which an origin server responds to requests, 5222 over time and over the varying dimensions of content negotiation, and 5223 thus the "sameness" of a resource's observed representations over 5224 time, is determined entirely by whatever entity or algorithm selects 5225 or generates those responses. 5227 12.1. Proactive Negotiation 5229 When content negotiation preferences are sent by the user agent in a 5230 request to encourage an algorithm located at the server to select the 5231 preferred representation, it is called _proactive negotiation_ 5232 (a.k.a., _server-driven negotiation_). Selection is based on the 5233 available representations for a response (the dimensions over which 5234 it might vary, such as language, content coding, etc.) compared to 5235 various information supplied in the request, including both the 5236 explicit negotiation header fields below and implicit 5237 characteristics, such as the client's network address or parts of the 5238 User-Agent field. 5240 Proactive negotiation is advantageous when the algorithm for 5241 selecting from among the available representations is difficult to 5242 describe to a user agent, or when the server desires to send its 5243 "best guess" to the user agent along with the first response (when 5244 that "best guess" is good enough for the user, this avoids the round 5245 trip delay of a subsequent request). In order to improve the 5246 server's guess, a user agent MAY send request header fields that 5247 describe its preferences. 5249 Proactive negotiation has serious disadvantages: 5251 * It is impossible for the server to accurately determine what might 5252 be "best" for any given user, since that would require complete 5253 knowledge of both the capabilities of the user agent and the 5254 intended use for the response (e.g., does the user want to view it 5255 on screen or print it on paper?); 5257 * Having the user agent describe its capabilities in every request 5258 can be both very inefficient (given that only a small percentage 5259 of responses have multiple representations) and a potential risk 5260 to the user's privacy; 5262 * It complicates the implementation of an origin server and the 5263 algorithms for generating responses to a request; and, 5265 * It limits the reusability of responses for shared caching. 5267 A user agent cannot rely on proactive negotiation preferences being 5268 consistently honored, since the origin server might not implement 5269 proactive negotiation for the requested resource or might decide that 5270 sending a response that doesn't conform to the user agent's 5271 preferences is better than sending a 406 (Not Acceptable) response. 5273 A Vary header field (Section 12.5.5) is often sent in a response 5274 subject to proactive negotiation to indicate what parts of the 5275 request information were used in the selection algorithm. 5277 The request header fields Accept, Accept-Charset, Accept-Encoding, 5278 and Accept-Language are defined below for a user agent to engage in 5279 proactive negotiation of the response content. The preferences sent 5280 in these fields apply to any content in the response, including 5281 representations of the target resource, representations of error or 5282 processing status, and potentially even the miscellaneous text 5283 strings that might appear within the protocol. 5285 12.2. Reactive Negotiation 5287 With _reactive negotiation_ (a.k.a., _agent-driven negotiation_), 5288 selection of content (regardless of the status code) is performed by 5289 the user agent after receiving an initial response. The mechanism 5290 for reactive negotiation might be as simple as a list of references 5291 to alternative representations. 5293 If the user agent is not satisfied by the initial response content, 5294 it can perform a GET request on one or more of the alternative 5295 resources to obtain a different representation. Selection of such 5296 alternatives might be performed automatically (by the user agent) or 5297 manually (e.g., by the user selecting from a hypertext menu). 5299 A server might choose not to send an initial representation, other 5300 than the list of alternatives, and thereby indicate that reactive 5301 negotiation by the user agent is preferred. For example, the 5302 alternatives listed in responses with the 300 (Multiple Choices) and 5303 406 (Not Acceptable) status codes include information about available 5304 representations so that the user or user agent can react by making a 5305 selection. 5307 Reactive negotiation is advantageous when the response would vary 5308 over commonly used dimensions (such as type, language, or encoding), 5309 when the origin server is unable to determine a user agent's 5310 capabilities from examining the request, and generally when public 5311 caches are used to distribute server load and reduce network usage. 5313 Reactive negotiation suffers from the disadvantages of transmitting a 5314 list of alternatives to the user agent, which degrades user-perceived 5315 latency if transmitted in the header section, and needing a second 5316 request to obtain an alternate representation. Furthermore, this 5317 specification does not define a mechanism for supporting automatic 5318 selection, though it does not prevent such a mechanism from being 5319 developed as an extension. 5321 12.3. Request Content Negotiation 5323 When content negotiation preferences are sent in a server's response, 5324 the listed preferences are called _request content negotiation_ 5325 because they intend to influence selection of an appropriate content 5326 for subsequent requests to that resource. For example, the Accept 5327 (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields 5328 can be sent in a response to indicate preferred media types and 5329 content codings for subsequent requests to that resource. 5331 Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" 5332 response header field which allows discovery of which content types 5333 are accepted in PATCH requests. 5335 12.4. Content Negotiation Field Features 5336 12.4.1. Absence 5338 For each of the content negotiation fields, a request that does not 5339 contain the field implies that the sender has no preference on that 5340 dimension of negotiation. 5342 If a content negotiation header field is present in a request and 5343 none of the available representations for the response can be 5344 considered acceptable according to it, the origin server can either 5345 honor the header field by sending a 406 (Not Acceptable) response or 5346 disregard the header field by treating the response as if it is not 5347 subject to content negotiation for that request header field. This 5348 does not imply, however, that the client will be able to use the 5349 representation. 5351 | *Note:* A user agent sending these header fields makes it 5352 | easier for a server to identify an individual by virtue of the 5353 | user agent's request characteristics (Section 17.13). 5355 12.4.2. Quality Values 5357 The content negotiation fields defined by this specification use a 5358 common parameter, named "q" (case-insensitive), to assign a relative 5359 "weight" to the preference for that associated kind of content. This 5360 weight is referred to as a "quality value" (or "qvalue") because the 5361 same parameter name is often used within server configurations to 5362 assign a weight to the relative quality of the various 5363 representations that can be selected for a resource. 5365 The weight is normalized to a real number in the range 0 through 1, 5366 where 0.001 is the least preferred and 1 is the most preferred; a 5367 value of 0 means "not acceptable". If no "q" parameter is present, 5368 the default weight is 1. 5370 weight = OWS ";" OWS "q=" qvalue 5371 qvalue = ( "0" [ "." 0*3DIGIT ] ) 5372 / ( "1" [ "." 0*3("0") ] ) 5374 A sender of qvalue MUST NOT generate more than three digits after the 5375 decimal point. User configuration of these values ought to be 5376 limited in the same fashion. 5378 12.4.3. Wildcard Values 5380 Most of these header fields, where indicated, define a wildcard value 5381 ("*") to select unspecified values. If no wildcard is present, 5382 values that are not explicitly mentioned in the field are considered 5383 unacceptable. Within Vary, the wildcard value means that the 5384 variance is unlimited. 5386 | *Note:* In practice, using wildcards in content negotiation has 5387 | limited practical value, because it is seldom useful to say, 5388 | for example, "I prefer image/* more or less than (some other 5389 | specific value)". Clients can explicitly request a 406 (Not 5390 | Acceptable) response if a more preferred format is not 5391 | available by sending Accept: */*;q=0, but they still need to be 5392 | able to handle a different response, since the server is 5393 | allowed to ignore their preference. 5395 12.5. Content Negotiation Fields 5397 12.5.1. Accept 5399 The "Accept" header field can be used by user agents to specify their 5400 preferences regarding response media types. For example, Accept 5401 header fields can be used to indicate that the request is 5402 specifically limited to a small set of desired types, as in the case 5403 of a request for an in-line image. 5405 When sent by a server in a response, Accept provides information 5406 about what content types are preferred in the content of a subsequent 5407 request to the same resource. 5409 Accept = #( media-range [ weight ] ) 5411 media-range = ( "*/*" 5412 / ( type "/" "*" ) 5413 / ( type "/" subtype ) 5414 ) parameters 5416 The asterisk "*" character is used to group media types into ranges, 5417 with "*/*" indicating all media types and "type/*" indicating all 5418 subtypes of that type. The media-range can include media type 5419 parameters that are applicable to that range. 5421 Each media-range might be followed by optional applicable media type 5422 parameters (e.g., charset), followed by an optional "q" parameter for 5423 indicating a relative weight (Section 12.4.2). 5425 Previous specifications allowed additional extension parameters to 5426 appear after the weight parameter. The accept extension grammar 5427 (accept-params, accept-ext) has been removed because it had a 5428 complicated definition, was not being used in practice, and is more 5429 easily deployed through new header fields. Senders using weights 5430 SHOULD send "q" last (after all media-range parameters). Recipients 5431 SHOULD process any parameter named "q" as weight, regardless of 5432 parameter ordering. 5434 | *Note:* Use of the "q" parameter name to control content 5435 | negotiation is due to historical practice. Although this 5436 | prevents any media type parameter named "q" from being used 5437 | with a media range, such an event is believed to be unlikely 5438 | given the lack of any "q" parameters in the IANA media type 5439 | registry and the rare usage of any media type parameters in 5440 | Accept. Future media types are discouraged from registering 5441 | any parameter named "q". 5443 The example 5445 Accept: audio/*; q=0.2, audio/basic 5447 is interpreted as "I prefer audio/basic, but send me any audio type 5448 if it is the best available after an 80% markdown in quality". 5450 A more elaborate example is 5452 Accept: text/plain; q=0.5, text/html, 5453 text/x-dvi; q=0.8, text/x-c 5455 Verbally, this would be interpreted as "text/html and text/x-c are 5456 the equally preferred media types, but if they do not exist, then 5457 send the text/x-dvi representation, and if that does not exist, send 5458 the text/plain representation". 5460 Media ranges can be overridden by more specific media ranges or 5461 specific media types. If more than one media range applies to a 5462 given type, the most specific reference has precedence. For example, 5464 Accept: text/*, text/plain, text/plain;format=flowed, */* 5466 have the following precedence: 5468 1. text/plain;format=flowed 5470 2. text/plain 5472 3. text/* 5473 4. */* 5475 The media type quality factor associated with a given type is 5476 determined by finding the media range with the highest precedence 5477 that matches the type. For example, 5479 Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, 5480 text/plain;format=fixed;q=0.4, */*;q=0.5 5482 would cause the following values to be associated: 5484 +==========================+===============+ 5485 | Media Type | Quality Value | 5486 +==========================+===============+ 5487 | text/plain;format=flowed | 1 | 5488 +--------------------------+---------------+ 5489 | text/plain | 0.7 | 5490 +--------------------------+---------------+ 5491 | text/html | 0.3 | 5492 +--------------------------+---------------+ 5493 | image/jpeg | 0.5 | 5494 +--------------------------+---------------+ 5495 | text/plain;format=fixed | 0.4 | 5496 +--------------------------+---------------+ 5497 | text/html;level=3 | 0.7 | 5498 +--------------------------+---------------+ 5500 Table 5 5502 | *Note:* A user agent might be provided with a default set of 5503 | quality values for certain media ranges. However, unless the 5504 | user agent is a closed system that cannot interact with other 5505 | rendering agents, this default set ought to be configurable by 5506 | the user. 5508 12.5.2. Accept-Charset 5510 The "Accept-Charset" header field can be sent by a user agent to 5511 indicate its preferences for charsets in textual response content. 5512 For example, this field allows user agents capable of understanding 5513 more comprehensive or special-purpose charsets to signal that 5514 capability to an origin server that is capable of representing 5515 information in those charsets. 5517 Accept-Charset = #( ( token / "*" ) [ weight ] ) 5519 Charset names are defined in Section 8.3.2. A user agent MAY 5520 associate a quality value with each charset to indicate the user's 5521 relative preference for that charset, as defined in Section 12.4.2. 5522 An example is 5524 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 5526 The special value "*", if present in the Accept-Charset header field, 5527 matches every charset that is not mentioned elsewhere in the field. 5529 | *Note:* Accept-Charset is deprecated because UTF-8 has become 5530 | nearly ubiquitous and sending a detailed list of user-preferred 5531 | charsets wastes bandwidth, increases latency, and makes passive 5532 | fingerprinting far too easy (Section 17.13). Most general- 5533 | purpose user agents do not send Accept-Charset, unless 5534 | specifically configured to do so. 5536 12.5.3. Accept-Encoding 5538 The "Accept-Encoding" header field can be used to indicate 5539 preferences regarding the use of content codings (Section 8.4.1). 5541 When sent by a user agent in a request, Accept-Encoding indicates the 5542 content codings acceptable in a response. 5544 When sent by a server in a response, Accept-Encoding provides 5545 information about what content codings are preferred in the content 5546 of a subsequent request to the same resource. 5548 An "identity" token is used as a synonym for "no encoding" in order 5549 to communicate when no encoding is preferred. 5551 Accept-Encoding = #( codings [ weight ] ) 5552 codings = content-coding / "identity" / "*" 5554 Each codings value MAY be given an associated quality value 5555 representing the preference for that encoding, as defined in 5556 Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field 5557 matches any available content coding not explicitly listed in the 5558 field. 5560 For example, 5562 Accept-Encoding: compress, gzip 5563 Accept-Encoding: 5564 Accept-Encoding: * 5565 Accept-Encoding: compress;q=0.5, gzip;q=1.0 5566 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 5567 A server tests whether a content coding for a given representation is 5568 acceptable using these rules: 5570 1. If no Accept-Encoding header field is in the request, any content 5571 coding is considered acceptable by the user agent. 5573 2. If the representation has no content coding, then it is 5574 acceptable by default unless specifically excluded by the Accept- 5575 Encoding header field stating either "identity;q=0" or "*;q=0" 5576 without a more specific entry for "identity". 5578 3. If the representation's content coding is one of the content 5579 codings listed in the Accept-Encoding field value, then it is 5580 acceptable unless it is accompanied by a qvalue of 0. (As 5581 defined in Section 12.4.2, a qvalue of 0 means "not acceptable".) 5583 A representation could be encoded with multiple content codings. 5584 However, most content codings are alternative ways to accomplish the 5585 same purpose (e.g., data compression). When selecting between 5586 multiple content codings that have the same purpose, the acceptable 5587 content coding with the highest non-zero qvalue is preferred. 5589 An Accept-Encoding header field with a field value that is empty 5590 implies that the user agent does not want any content coding in 5591 response. If an Accept-Encoding header field is present in a request 5592 and none of the available representations for the response have a 5593 content coding that is listed as acceptable, the origin server SHOULD 5594 send a response without any content coding. 5596 When the Accept-Encoding header field is present in a response, it 5597 indicates what content codings the resource was willing to accept in 5598 the associated request. The field value is evaluated the same way as 5599 in a request. 5601 Note that this information is specific to the associated request; the 5602 set of supported encodings might be different for other resources on 5603 the same server and could change over time or depend on other aspects 5604 of the request (such as the request method). 5606 Servers that fail a request due to an unsupported content coding 5607 ought to respond with a 415 (Unsupported Media Type) status and 5608 include an Accept-Encoding header field in that response, allowing 5609 clients to distinguish between issues related to content codings and 5610 media types. In order to avoid confusion with issues related to 5611 media types, servers that fail a request with a 415 status for 5612 reasons unrelated to content codings MUST NOT include the Accept- 5613 Encoding header field. 5615 The most common use of Accept-Encoding is in responses with a 415 5616 (Unsupported Media Type) status code, in response to optimistic use 5617 of a content coding by clients. However, the header field can also 5618 be used to indicate to clients that content codings are supported, to 5619 optimize future interactions. For example, a resource might include 5620 it in a 2xx (Successful) response when the request content was big 5621 enough to justify use of a compression coding but the client failed 5622 do so. 5624 | *Note:* Most HTTP/1.0 applications do not recognize or obey 5625 | qvalues associated with content-codings. This means that 5626 | qvalues might not work and are not permitted with x-gzip or 5627 | x-compress. 5629 12.5.4. Accept-Language 5631 The "Accept-Language" header field can be used by user agents to 5632 indicate the set of natural languages that are preferred in the 5633 response. Language tags are defined in Section 8.5.1. 5635 Accept-Language = #( language-range [ weight ] ) 5636 language-range = 5637 5639 Each language-range can be given an associated quality value 5640 representing an estimate of the user's preference for the languages 5641 specified by that range, as defined in Section 12.4.2. For example, 5643 Accept-Language: da, en-gb;q=0.8, en;q=0.7 5645 would mean: "I prefer Danish, but will accept British English and 5646 other types of English". 5648 Note that some recipients treat the order in which language tags are 5649 listed as an indication of descending priority, particularly for tags 5650 that are assigned equal quality values (no value is the same as q=1). 5651 However, this behavior cannot be relied upon. For consistency and to 5652 maximize interoperability, many user agents assign each language tag 5653 a unique quality value while also listing them in order of decreasing 5654 quality. Additional discussion of language priority lists can be 5655 found in Section 2.3 of [RFC4647]. 5657 For matching, Section 3 of [RFC4647] defines several matching 5658 schemes. Implementations can offer the most appropriate matching 5659 scheme for their requirements. The "Basic Filtering" scheme 5660 ([RFC4647], Section 3.3.1) is identical to the matching scheme that 5661 was previously defined for HTTP in Section 14.4 of [RFC2616]. 5663 It might be contrary to the privacy expectations of the user to send 5664 an Accept-Language header field with the complete linguistic 5665 preferences of the user in every request (Section 17.13). 5667 Since intelligibility is highly dependent on the individual user, 5668 user agents need to allow user control over the linguistic preference 5669 (either through configuration of the user agent itself or by 5670 defaulting to a user controllable system setting). A user agent that 5671 does not provide such control to the user MUST NOT send an Accept- 5672 Language header field. 5674 | *Note:* User agents ought to provide guidance to users when 5675 | setting a preference, since users are rarely familiar with the 5676 | details of language matching as described above. For example, 5677 | users might assume that on selecting "en-gb", they will be 5678 | served any kind of English document if British English is not 5679 | available. A user agent might suggest, in such a case, to add 5680 | "en" to the list for better matching behavior. 5682 12.5.5. Vary 5684 The "Vary" header field in a response describes what parts of a 5685 request message, aside from the method and target URI, might 5686 influence the origin server's process for selecting and representing 5687 this response. 5689 Vary = #( "*" / field-name ) 5691 A Vary field value is a list of request field names, known as the 5692 selecting header fields, that might have a role in selecting the 5693 representation for this response. Potential selecting header fields 5694 are not limited to those defined by this specification. 5696 If the list contains "*", it signals that other aspects of the 5697 request might play a role in selecting the response representation, 5698 possibly including elements outside the message syntax (e.g., the 5699 client's network address). A recipient will not be able to determine 5700 whether this response is appropriate for a later request without 5701 forwarding the request to the origin server. A proxy MUST NOT 5702 generate "*" in a Vary field value. 5704 For example, a response that contains 5706 Vary: accept-encoding, accept-language 5708 indicates that the origin server might have used the request's 5709 Accept-Encoding and Accept-Language header fields (or lack thereof) 5710 as determining factors while choosing the content for this response. 5712 An origin server might send Vary with a list of header fields for two 5713 purposes: 5715 1. To inform cache recipients that they MUST NOT use this response 5716 to satisfy a later request unless the later request has the same 5717 values for the listed header fields as the original request 5718 (Section 4.1 of [CACHING]). In other words, Vary expands the 5719 cache key required to match a new request to the stored cache 5720 entry. 5722 2. To inform user agent recipients that this response is subject to 5723 content negotiation (Section 12) and that a different 5724 representation might be sent in a subsequent request if 5725 additional parameters are provided in the listed header fields 5726 (proactive negotiation). 5728 An origin server SHOULD send a Vary header field when its algorithm 5729 for selecting a representation varies based on aspects of the request 5730 message other than the method and target URI, unless the variance 5731 cannot be crossed or the origin server has been deliberately 5732 configured to prevent cache transparency. For example, there is no 5733 need to send the Authorization field name in Vary because reuse 5734 across users is constrained by the field definition (Section 11.6.2). 5735 Likewise, an origin server might use Cache-Control response 5736 directives (Section 5.2 of [CACHING]) to supplant Vary if it 5737 considers the variance less significant than the performance cost of 5738 Vary's impact on caching. 5740 13. Conditional Requests 5742 A conditional request is an HTTP request with one or more request 5743 header fields that indicate a precondition to be tested before 5744 applying the request method to the target resource. Section 13.2 5745 defines when to evaluate preconditions and their order of precedence 5746 when more than one precondition is present. 5748 Conditional GET requests are the most efficient mechanism for HTTP 5749 cache updates [CACHING]. Conditionals can also be applied to state- 5750 changing methods, such as PUT and DELETE, to prevent the "lost 5751 update" problem: one client accidentally overwriting the work of 5752 another client that has been acting in parallel. 5754 13.1. Preconditions 5756 Preconditions are usually defined with respect to a state of the 5757 target resource as a whole (its current value set) or the state as 5758 observed in a previously obtained representation (one value in that 5759 set). If a resource has multiple current representations, each with 5760 its own observable state, a precondition will assume that the mapping 5761 of each request to a selected representation (Section 3.2) is 5762 consistent over time. Regardless, if the mapping is inconsistent or 5763 the server is unable to select an appropriate representation, then no 5764 harm will result when the precondition evaluates to false. 5766 Each precondition defined below consists of a comparison between a 5767 set of validators obtained from prior representations of the target 5768 resource to the current state of validators for the selected 5769 representation (Section 8.8). Hence, these preconditions evaluate 5770 whether the state of the target resource has changed since a given 5771 state known by the client. The effect of such an evaluation depends 5772 on the method semantics and choice of conditional, as defined in 5773 Section 13.2. 5775 Other preconditions, defined by other specifications as extension 5776 fields, might place conditions on all recipients, on the state of the 5777 target resource in general, or on a group of resources. For 5778 instance, the "If" header field in WebDAV can make a request 5779 conditional on various aspects of multiple resources, such as locks, 5780 if the recipient understands and implements that field ([WEBDAV], 5781 Section 10.4). 5783 Extensibility of preconditions is only possible when the precondition 5784 can be safely ignored if unknown (like If-Modified-Since), when 5785 deployment can be assumed for a given use case, or when 5786 implementation is signaled by some other property of the target 5787 resource. This encourages a focus on mutually agreed deployment of 5788 common standards. 5790 13.1.1. If-Match 5792 The "If-Match" header field makes the request method conditional on 5793 the recipient origin server either having at least one current 5794 representation of the target resource, when the field value is "*", 5795 or having a current representation of the target resource that has an 5796 entity-tag matching a member of the list of entity-tags provided in 5797 the field value. 5799 An origin server MUST use the strong comparison function when 5800 comparing entity-tags for If-Match (Section 8.8.3.2), since the 5801 client intends this precondition to prevent the method from being 5802 applied if there have been any changes to the representation data. 5804 If-Match = "*" / #entity-tag 5806 Examples: 5808 If-Match: "xyzzy" 5809 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 5810 If-Match: * 5812 If-Match is most often used with state-changing methods (e.g., POST, 5813 PUT, DELETE) to prevent accidental overwrites when multiple user 5814 agents might be acting in parallel on the same resource (i.e., to 5815 prevent the "lost update" problem). It can also be used with any 5816 method to abort a request if the selected representation does not 5817 match one that the client has already stored (or partially stored) 5818 from a prior request. 5820 An origin server that receives an If-Match header field MUST evaluate 5821 the condition as per Section 13.2 prior to performing the method. 5823 To evaluate a received If-Match header field: 5825 1. If the field value is "*", the condition is true if the origin 5826 server has a current representation for the target resource. 5828 2. If the field value is a list of entity-tags, the condition is 5829 true if any of the listed tags match the entity-tag of the 5830 selected representation. 5832 3. Otherwise, the condition is false. 5834 An origin server MUST NOT perform the requested method if a received 5835 If-Match condition evaluates to false. Instead, the origin server 5836 MAY indicate that the conditional request failed by responding with a 5837 412 (Precondition Failed) status code. Alternatively, if the request 5838 is a state-changing operation that appears to have already been 5839 applied to the selected representation, the origin server MAY respond 5840 with a 2xx (Successful) status code (i.e., the change requested by 5841 the user agent has already succeeded, but the user agent might not be 5842 aware of it, perhaps because the prior response was lost or an 5843 equivalent change was made by some other user agent). 5845 Allowing an origin server to send a success response when a change 5846 request appears to have already been applied is more efficient for 5847 many authoring use cases, but comes with some risk if multiple user 5848 agents are making change requests that are very similar but not 5849 cooperative. For example, multiple user agents writing to a common 5850 resource as a semaphore (e.g., a non-atomic increment) are likely to 5851 collide and potentially lose important state transitions. For those 5852 kinds of resources, an origin server is better off being stringent in 5853 sending 412 for every failed precondition on an unsafe method. In 5854 other cases, excluding the ETag field from a success response might 5855 encourage the user agent to perform a GET as its next request to 5856 eliminate confusion about the resource's current state. 5858 The If-Match header field can be ignored by caches and intermediaries 5859 because it is not applicable to a stored response. 5861 Note that an If-Match header field with a list value containing "*" 5862 and other values (including other instances of "*") is syntactically 5863 invalid (therefore not allowed to be generated) and furthermore is 5864 unlikely to be interoperable. 5866 13.1.2. If-None-Match 5868 The "If-None-Match" header field makes the request method conditional 5869 on a recipient cache or origin server either not having any current 5870 representation of the target resource, when the field value is "*", 5871 or having a selected representation with an entity-tag that does not 5872 match any of those listed in the field value. 5874 A recipient MUST use the weak comparison function when comparing 5875 entity-tags for If-None-Match (Section 8.8.3.2), since weak entity- 5876 tags can be used for cache validation even if there have been changes 5877 to the representation data. 5879 If-None-Match = "*" / #entity-tag 5881 Examples: 5883 If-None-Match: "xyzzy" 5884 If-None-Match: W/"xyzzy" 5885 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 5886 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" 5887 If-None-Match: * 5889 If-None-Match is primarily used in conditional GET requests to enable 5890 efficient updates of cached information with a minimum amount of 5891 transaction overhead. When a client desires to update one or more 5892 stored responses that have entity-tags, the client SHOULD generate an 5893 If-None-Match header field containing a list of those entity-tags 5894 when making a GET request; this allows recipient servers to send a 5895 304 (Not Modified) response to indicate when one of those stored 5896 responses matches the selected representation. 5898 If-None-Match can also be used with a value of "*" to prevent an 5899 unsafe request method (e.g., PUT) from inadvertently modifying an 5900 existing representation of the target resource when the client 5901 believes that the resource does not have a current representation 5902 (Section 9.2.1). This is a variation on the "lost update" problem 5903 that might arise if more than one client attempts to create an 5904 initial representation for the target resource. 5906 An origin server that receives an If-None-Match header field MUST 5907 evaluate the condition as per Section 13.2 prior to performing the 5908 method. 5910 To evaluate a received If-None-Match header field: 5912 1. If the field value is "*", the condition is false if the origin 5913 server has a current representation for the target resource. 5915 2. If the field value is a list of entity-tags, the condition is 5916 false if one of the listed tags matches the entity-tag of the 5917 selected representation. 5919 3. Otherwise, the condition is true. 5921 An origin server MUST NOT perform the requested method if a received 5922 If-None-Match condition evaluates to false; instead, the origin 5923 server MUST respond with either a) the 304 (Not Modified) status code 5924 if the request method is GET or HEAD or b) the 412 (Precondition 5925 Failed) status code for all other request methods. 5927 Requirements on cache handling of a received If-None-Match header 5928 field are defined in Section 4.3.2 of [CACHING]. 5930 Note that an If-None-Match header field with a list value containing 5931 "*" and other values (including other instances of "*") is 5932 syntactically invalid (therefore not allowed to be generated) and 5933 furthermore is unlikely to be interoperable. 5935 13.1.3. If-Modified-Since 5937 The "If-Modified-Since" header field makes a GET or HEAD request 5938 method conditional on the selected representation's modification date 5939 being more recent than the date provided in the field value. 5940 Transfer of the selected representation's data is avoided if that 5941 data has not changed. 5943 If-Modified-Since = HTTP-date 5945 An example of the field is: 5947 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 5949 A recipient MUST ignore If-Modified-Since if the request contains an 5950 If-None-Match header field; the condition in If-None-Match is 5951 considered to be a more accurate replacement for the condition in If- 5952 Modified-Since, and the two are only combined for the sake of 5953 interoperating with older intermediaries that might not implement 5954 If-None-Match. 5956 A recipient MUST ignore the If-Modified-Since header field if the 5957 received field value is not a valid HTTP-date, the field value has 5958 more than one member, or if the request method is neither GET nor 5959 HEAD. 5961 A recipient MUST interpret an If-Modified-Since field value's 5962 timestamp in terms of the origin server's clock. 5964 If-Modified-Since is typically used for two distinct purposes: 1) to 5965 allow efficient updates of a cached representation that does not have 5966 an entity-tag and 2) to limit the scope of a web traversal to 5967 resources that have recently changed. 5969 When used for cache updates, a cache will typically use the value of 5970 the cached message's Last-Modified header field to generate the field 5971 value of If-Modified-Since. This behavior is most interoperable for 5972 cases where clocks are poorly synchronized or when the server has 5973 chosen to only honor exact timestamp matches (due to a problem with 5974 Last-Modified dates that appear to go "back in time" when the origin 5975 server's clock is corrected or a representation is restored from an 5976 archived backup). However, caches occasionally generate the field 5977 value based on other data, such as the Date header field of the 5978 cached message or the local clock time that the message was received, 5979 particularly when the cached message does not contain a Last-Modified 5980 header field. 5982 When used for limiting the scope of retrieval to a recent time 5983 window, a user agent will generate an If-Modified-Since field value 5984 based on either its own local clock or a Date header field received 5985 from the server in a prior response. Origin servers that choose an 5986 exact timestamp match based on the selected representation's 5987 Last-Modified header field will not be able to help the user agent 5988 limit its data transfers to only those changed during the specified 5989 window. 5991 An origin server that receives an If-Modified-Since header field 5992 SHOULD evaluate the condition as per Section 13.2 prior to performing 5993 the method. 5995 To evaluate a received If-Modified-Since header field: 5997 1. If the selected representation's last modification date is 5998 earlier or equal to the date provided in the field value, the 5999 condition is false. 6001 2. Otherwise, the condition is true. 6003 An origin server SHOULD NOT perform the requested method if a 6004 received If-Modified-Since condition evaluates to false; instead, the 6005 origin server SHOULD generate a 304 (Not Modified) response, 6006 including only those metadata that are useful for identifying or 6007 updating a previously cached response. 6009 Requirements on cache handling of a received If-Modified-Since header 6010 field are defined in Section 4.3.2 of [CACHING]. 6012 13.1.4. If-Unmodified-Since 6014 The "If-Unmodified-Since" header field makes the request method 6015 conditional on the selected representation's last modification date 6016 being earlier than or equal to the date provided in the field value. 6017 This field accomplishes the same purpose as If-Match for cases where 6018 the user agent does not have an entity-tag for the representation. 6020 If-Unmodified-Since = HTTP-date 6022 An example of the field is: 6024 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6025 A recipient MUST ignore If-Unmodified-Since if the request contains 6026 an If-Match header field; the condition in If-Match is considered to 6027 be a more accurate replacement for the condition in If-Unmodified- 6028 Since, and the two are only combined for the sake of interoperating 6029 with older intermediaries that might not implement If-Match. 6031 A recipient MUST ignore the If-Unmodified-Since header field if the 6032 received field value is not a valid HTTP-date (including when the 6033 field value appears to be a list of dates). 6035 A recipient MUST interpret an If-Unmodified-Since field value's 6036 timestamp in terms of the origin server's clock. 6038 If-Unmodified-Since is most often used with state-changing methods 6039 (e.g., POST, PUT, DELETE) to prevent accidental overwrites when 6040 multiple user agents might be acting in parallel on a resource that 6041 does not supply entity-tags with its representations (i.e., to 6042 prevent the "lost update" problem). It can also be used with any 6043 method to abort a request if the selected representation does not 6044 match one that the client already stored (or partially stored) from a 6045 prior request. 6047 An origin server that receives an If-Unmodified-Since header field 6048 without an If-Match header field MUST evaluate the condition as per 6049 Section 13.2 prior to performing the method. 6051 To evaluate a received If-Unmodified-Since header field: 6053 1. If the selected representation's last modification date is 6054 earlier than or equal to the date provided in the field value, 6055 the condition is true. 6057 2. Otherwise, the condition is false. 6059 An origin server MUST NOT perform the requested method if an If- 6060 Unmodified-Since condition evaluates to false. Instead, the origin 6061 server MAY indicate that the conditional request failed by responding 6062 with a 412 (Precondition Failed) status code. Alternatively, if the 6063 request is a state-changing operation that appears to have already 6064 been applied to the selected representation, the origin server MAY 6065 respond with a 2xx (Successful) status code (i.e., the change 6066 requested by the user agent has already succeeded, but the user agent 6067 might not be aware of it, perhaps because the prior response was lost 6068 or an equivalent change was made by some other user agent). 6070 Allowing an origin server to send a success response when a change 6071 request appears to have already been applied is more efficient for 6072 many authoring use cases, but comes with some risk if multiple user 6073 agents are making change requests that are very similar but not 6074 cooperative. In those cases, an origin server is better off being 6075 stringent in sending 412 for every failed precondition on an unsafe 6076 method. 6078 The If-Unmodified-Since header field can be ignored by caches and 6079 intermediaries because it is not applicable to a stored response. 6081 13.1.5. If-Range 6083 The "If-Range" header field provides a special conditional request 6084 mechanism that is similar to the If-Match and If-Unmodified-Since 6085 header fields but that instructs the recipient to ignore the Range 6086 header field if the validator doesn't match, resulting in transfer of 6087 the new selected representation instead of a 412 (Precondition 6088 Failed) response. 6090 If a client has a partial copy of a representation and wishes to have 6091 an up-to-date copy of the entire representation, it could use the 6092 Range header field with a conditional GET (using either or both of 6093 If-Unmodified-Since and If-Match.) However, if the precondition 6094 fails because the representation has been modified, the client would 6095 then have to make a second request to obtain the entire current 6096 representation. 6098 The "If-Range" header field allows a client to "short-circuit" the 6099 second request. Informally, its meaning is as follows: if the 6100 representation is unchanged, send me the part(s) that I am requesting 6101 in Range; otherwise, send me the entire representation. 6103 If-Range = entity-tag / HTTP-date 6105 A valid entity-tag can be distinguished from a valid HTTP-date by 6106 examining the first three characters for a DQUOTE. 6108 A client MUST NOT generate an If-Range header field in a request that 6109 does not contain a Range header field. A server MUST ignore an If- 6110 Range header field received in a request that does not contain a 6111 Range header field. An origin server MUST ignore an If-Range header 6112 field received in a request for a target resource that does not 6113 support Range requests. 6115 A client MUST NOT generate an If-Range header field containing an 6116 entity-tag that is marked as weak. A client MUST NOT generate an If- 6117 Range header field containing an HTTP-date unless the client has no 6118 entity-tag for the corresponding representation and the date is a 6119 strong validator in the sense defined by Section 8.8.2.2. 6121 A server that receives an If-Range header field on a Range request 6122 MUST evaluate the condition as per Section 13.2 prior to performing 6123 the method. 6125 To evaluate a received If-Range header field containing an HTTP-date: 6127 1. If the HTTP-date validator provided is not a strong validator in 6128 the sense defined by Section 8.8.2.2, the condition is false. 6130 2. If the HTTP-date validator provided exactly matches the 6131 Last-Modified field value for the selected representation, the 6132 condition is true. 6134 3. Otherwise, the condition is false. 6136 To evaluate a received If-Range header field containing an 6137 entity-tag: 6139 1. If the entity-tag validator provided exactly matches the ETag 6140 field value for the selected representation using the strong 6141 comparison function (Section 8.8.3.2), the condition is true. 6143 2. Otherwise, the condition is false. 6145 A recipient of an If-Range header field MUST ignore the Range header 6146 field if the If-Range condition evaluates to false. Otherwise, the 6147 recipient SHOULD process the Range header field as requested. 6149 Note that the If-Range comparison is by exact match, including when 6150 the validator is an HTTP-date, and so differs from the "earlier than 6151 or equal to" comparison used when evaluating an If-Unmodified-Since 6152 conditional. 6154 13.2. Evaluation of Preconditions 6156 13.2.1. When to Evaluate 6158 Except when excluded below, a recipient cache or origin server MUST 6159 evaluate received request preconditions after it has successfully 6160 performed its normal request checks and just before it would process 6161 the request content (if any) or perform the action associated with 6162 the request method. A server MUST ignore all received preconditions 6163 if its response to the same request without those conditions, prior 6164 to processing the request content, would have been a status code 6165 other than a 2xx (Successful) or 412 (Precondition Failed). In other 6166 words, redirects and failures that can be detected before significant 6167 processing occurs take precedence over the evaluation of 6168 preconditions. 6170 A server that is not the origin server for the target resource and 6171 cannot act as a cache for requests on the target resource MUST NOT 6172 evaluate the conditional request header fields defined by this 6173 specification, and it MUST forward them if the request is forwarded, 6174 since the generating client intends that they be evaluated by a 6175 server that can provide a current representation. Likewise, a server 6176 MUST ignore the conditional request header fields defined by this 6177 specification when received with a request method that does not 6178 involve the selection or modification of a selected representation, 6179 such as CONNECT, OPTIONS, or TRACE. 6181 Note that protocol extensions can modify the conditions under which 6182 preconditions are evaluated or the consequences of their evaluation. 6183 For example, the "immutable" cache directive (defined by [RFC8246]) 6184 instructs caches to forgo forwarding conditional requests when they 6185 hold a fresh response. 6187 Although conditional request header fields are defined as being 6188 usable with the HEAD method (to keep HEAD's semantics consistent with 6189 those of GET), there is no point in sending a conditional HEAD 6190 because a successful response is around the same size as a 304 (Not 6191 Modified) response and more useful than a 412 (Precondition Failed) 6192 response. 6194 13.2.2. Precedence of Preconditions 6196 When more than one conditional request header field is present in a 6197 request, the order in which the fields are evaluated becomes 6198 important. In practice, the fields defined in this document are 6199 consistently implemented in a single, logical order, since "lost 6200 update" preconditions have more strict requirements than cache 6201 validation, a validated cache is more efficient than a partial 6202 response, and entity tags are presumed to be more accurate than date 6203 validators. 6205 A recipient cache or origin server MUST evaluate the request 6206 preconditions defined by this specification in the following order: 6208 1. When recipient is the origin server and If-Match is present, 6209 evaluate the If-Match precondition: 6211 * if true, continue to step 3 6213 * if false, respond 412 (Precondition Failed) unless it can be 6214 determined that the state-changing request has already 6215 succeeded (see Section 13.1.1) 6217 2. When recipient is the origin server, If-Match is not present, and 6218 If-Unmodified-Since is present, evaluate the If-Unmodified-Since 6219 precondition: 6221 * if true, continue to step 3 6223 * if false, respond 412 (Precondition Failed) unless it can be 6224 determined that the state-changing request has already 6225 succeeded (see Section 13.1.4) 6227 3. When If-None-Match is present, evaluate the If-None-Match 6228 precondition: 6230 * if true, continue to step 5 6232 * if false for GET/HEAD, respond 304 (Not Modified) 6234 * if false for other methods, respond 412 (Precondition Failed) 6236 4. When the method is GET or HEAD, If-None-Match is not present, and 6237 If-Modified-Since is present, evaluate the If-Modified-Since 6238 precondition: 6240 * if true, continue to step 5 6242 * if false, respond 304 (Not Modified) 6244 5. When the method is GET and both Range and If-Range are present, 6245 evaluate the If-Range precondition: 6247 * if the validator matches and the Range specification is 6248 applicable to the selected representation, respond 206 6249 (Partial Content) 6251 6. Otherwise, 6253 * all conditions are met, so perform the requested action and 6254 respond according to its success or failure. 6256 Any extension to HTTP that defines additional conditional request 6257 header fields ought to define the order for evaluating such fields in 6258 relation to those defined in this document and other conditionals 6259 that might be found in practice. 6261 14. Range Requests 6263 Clients often encounter interrupted data transfers as a result of 6264 canceled requests or dropped connections. When a client has stored a 6265 partial representation, it is desirable to request the remainder of 6266 that representation in a subsequent request rather than transfer the 6267 entire representation. Likewise, devices with limited local storage 6268 might benefit from being able to request only a subset of a larger 6269 representation, such as a single page of a very large document, or 6270 the dimensions of an embedded image. 6272 Range requests are an OPTIONAL feature of HTTP, designed so that 6273 recipients not implementing this feature (or not supporting it for 6274 the target resource) can respond as if it is a normal GET request 6275 without impacting interoperability. Partial responses are indicated 6276 by a distinct status code to not be mistaken for full responses by 6277 caches that might not implement the feature. 6279 14.1. Range Units 6281 Representation data can be partitioned into subranges when there are 6282 addressable structural units inherent to that data's content coding 6283 or media type. For example, octet (a.k.a., byte) boundaries are a 6284 structural unit common to all representation data, allowing 6285 partitions of the data to be identified as a range of bytes at some 6286 offset from the start or end of that data. 6288 This general notion of a _range unit_ is used in the Accept-Ranges 6289 (Section 14.3) response header field to advertise support for range 6290 requests, the Range (Section 14.2) request header field to delineate 6291 the parts of a representation that are requested, and the 6292 Content-Range (Section 14.4) header field to describe which part of a 6293 representation is being transferred. 6295 range-unit = token 6297 All range unit names are case-insensitive and ought to be registered 6298 within the "HTTP Range Unit Registry", as defined in Section 16.5.1. 6300 Range units are intended to be extensible, as described in 6301 Section 16.5. 6303 14.1.1. Range Specifiers 6305 Ranges are expressed in terms of a range unit paired with a set of 6306 range specifiers. The range unit name determines what kinds of 6307 range-spec are applicable to its own specifiers. Hence, the 6308 following grammar is generic: each range unit is expected to specify 6309 requirements on when int-range, suffix-range, and other-range are 6310 allowed. 6312 A range request can specify a single range or a set of ranges within 6313 a single representation. 6315 ranges-specifier = range-unit "=" range-set 6316 range-set = 1#range-spec 6317 range-spec = int-range 6318 / suffix-range 6319 / other-range 6321 An int-range is a range expressed as two non-negative integers or as 6322 one non-negative integer through to the end of the representation 6323 data. The range unit specifies what the integers mean (e.g., they 6324 might indicate unit offsets from the beginning, inclusive numbered 6325 parts, etc.). 6327 int-range = first-pos "-" [ last-pos ] 6328 first-pos = 1*DIGIT 6329 last-pos = 1*DIGIT 6331 An int-range is invalid if the last-pos value is present and less 6332 than the first-pos. 6334 A suffix-range is a range expressed as a suffix of the representation 6335 data with the provided non-negative integer maximum length (in range 6336 units). In other words, the last N units of the representation data. 6338 suffix-range = "-" suffix-length 6339 suffix-length = 1*DIGIT 6341 To provide for extensibility, the other-range rule is a mostly 6342 unconstrained grammar that allows application-specific or future 6343 range units to define additional range specifiers. 6345 other-range = 1*( %x21-2B / %x2D-7E ) 6346 ; 1*(VCHAR excluding comma) 6348 14.1.2. Byte Ranges 6350 The "bytes" range unit is used to express subranges of a 6351 representation data's octet sequence. Each byte range is expressed 6352 as an integer range at some offset, relative to either the beginning 6353 (int-range) or end (suffix-range) of the representation data. Byte 6354 ranges do not use the other-range specifier. 6356 The first-pos value in a bytes int-range gives the offset of the 6357 first byte in a range. The last-pos value gives the offset of the 6358 last byte in the range; that is, the byte positions specified are 6359 inclusive. Byte offsets start at zero. 6361 If the representation data has a content coding applied, each byte 6362 range is calculated with respect to the encoded sequence of bytes, 6363 not the sequence of underlying bytes that would be obtained after 6364 decoding. 6366 Examples of bytes range specifiers: 6368 * The first 500 bytes (byte offsets 0-499, inclusive): 6370 bytes=0-499 6372 * The second 500 bytes (byte offsets 500-999, inclusive): 6374 bytes=500-999 6376 A client can limit the number of bytes requested without knowing the 6377 size of the selected representation. If the last-pos value is 6378 absent, or if the value is greater than or equal to the current 6379 length of the representation data, the byte range is interpreted as 6380 the remainder of the representation (i.e., the server replaces the 6381 value of last-pos with a value that is one less than the current 6382 length of the selected representation). 6384 A client can request the last N bytes (N > 0) of the selected 6385 representation using a suffix-range. If the selected representation 6386 is shorter than the specified suffix-length, the entire 6387 representation is used. 6389 Additional examples, assuming a representation of length 10000: 6391 * The final 500 bytes (byte offsets 9500-9999, inclusive): 6393 bytes=-500 6395 Or: 6397 bytes=9500- 6399 * The first and last bytes only (bytes 0 and 9999): 6401 bytes=0-0,-1 6403 * The first, middle, and last 1000 bytes: 6405 bytes= 0-999, 4500-5499, -1000 6407 * Other valid (but not canonical) specifications of the second 500 6408 bytes (byte offsets 500-999, inclusive): 6410 bytes=500-600,601-999 6411 bytes=500-700,601-999 6413 If a valid bytes range-set includes at least one range-spec with a 6414 first-pos that is less than the current length of the representation, 6415 or at least one suffix-range with a non-zero suffix-length, then the 6416 bytes range-set is satisfiable. Otherwise, the bytes range-set is 6417 unsatisfiable. 6419 If the selected representation has zero length, the only satisfiable 6420 form of range-spec is a suffix-range with a non-zero suffix-length. 6422 In the byte-range syntax, first-pos, last-pos, and suffix-length are 6423 expressed as decimal number of octets. Since there is no predefined 6424 limit to the length of content, recipients MUST anticipate 6425 potentially large decimal numerals and prevent parsing errors due to 6426 integer conversion overflows. 6428 14.2. Range 6430 The "Range" header field on a GET request modifies the method 6431 semantics to request transfer of only one or more subranges of the 6432 selected representation data (Section 8.1), rather than the entire 6433 selected representation. 6435 Range = ranges-specifier 6437 A server MAY ignore the Range header field. However, origin servers 6438 and intermediate caches ought to support byte ranges when possible, 6439 since they support efficient recovery from partially failed transfers 6440 and partial retrieval of large representations. 6442 A server MUST ignore a Range header field received with a request 6443 method which is unrecognized or for which range handling is not 6444 defined. For this specification, GET is the only method for which 6445 range handling is defined. 6447 An origin server MUST ignore a Range header field that contains a 6448 range unit it does not understand. A proxy MAY discard a Range 6449 header field that contains a range unit it does not understand. 6451 A server that supports range requests MAY ignore or reject a Range 6452 header field that consists of more than two overlapping ranges, or a 6453 set of many small ranges that are not listed in ascending order, 6454 since both are indications of either a broken client or a deliberate 6455 denial-of-service attack (Section 17.15). A client SHOULD NOT 6456 request multiple ranges that are inherently less efficient to process 6457 and transfer than a single range that encompasses the same data. 6459 A server that supports range requests MAY ignore a Range header field 6460 when the selected representation has no content (i.e., the selected 6461 representation's data is of zero length). 6463 A client that is requesting multiple ranges SHOULD list those ranges 6464 in ascending order (the order in which they would typically be 6465 received in a complete representation) unless there is a specific 6466 need to request a later part earlier. For example, a user agent 6467 processing a large representation with an internal catalog of parts 6468 might need to request later parts first, particularly if the 6469 representation consists of pages stored in reverse order and the user 6470 agent wishes to transfer one page at a time. 6472 The Range header field is evaluated after evaluating the precondition 6473 header fields defined in Section 13.1, and only if the result in 6474 absence of the Range header field would be a 200 (OK) response. In 6475 other words, Range is ignored when a conditional GET would result in 6476 a 304 (Not Modified) response. 6478 The If-Range header field (Section 13.1.5) can be used as a 6479 precondition to applying the Range header field. 6481 If all of the preconditions are true, the server supports the Range 6482 header field for the target resource, and the specified range(s) are 6483 valid and satisfiable (as defined in Section 14.1.2), the server 6484 SHOULD send a 206 (Partial Content) response with a content 6485 containing one or more partial representations that correspond to the 6486 satisfiable ranges requested. 6488 The above does not imply that a server will send all requested 6489 ranges. In some cases, it may only be possible (or efficient) to 6490 send a portion of the requested ranges first, while expecting the 6491 client to re-request the remaining portions later if they are still 6492 desired (see Section 15.3.7). 6494 If all of the preconditions are true, the server supports the Range 6495 header field for the target resource, and the specified range(s) are 6496 invalid or unsatisfiable, the server SHOULD send a 416 (Range Not 6497 Satisfiable) response. 6499 14.3. Accept-Ranges 6501 The "Accept-Ranges" field in a response indicates whether an upstream 6502 server supports range requests for the target resource. 6504 Accept-Ranges = acceptable-ranges 6505 acceptable-ranges = 1#range-unit 6507 For example, a server that supports byte-range requests 6508 (Section 14.1.2) can send the field 6510 Accept-Ranges: bytes 6512 to indicate that it supports byte range requests for that target 6513 resource, thereby encouraging its use by the client for future 6514 partial requests on the same request path. Range units are defined 6515 in Section 14.1. 6517 A client MAY generate range requests regardless of having received an 6518 Accept-Ranges field. The information only provides advice for the 6519 sake of improving performance and reducing unnecessary network 6520 transfers. 6522 Conversely, a client MUST NOT assume that receiving an Accept-Ranges 6523 field means that future range requests will return partial responses. 6524 The content might change, the server might only support range 6525 requests at certain times or under certain conditions, or a different 6526 intermediary might process the next request. 6528 A server that does not support any kind of range request for the 6529 target resource MAY send 6531 Accept-Ranges: none 6533 to advise the client not to attempt a range request on the same 6534 request path. The range unit "none" is reserved for this purpose. 6536 The Accept-Ranges field MAY be sent in a trailer section, but is 6537 preferred to be sent as a header field because the information is 6538 particularly useful for restarting large information transfers that 6539 have failed in mid-content (before the trailer section is received). 6541 14.4. Content-Range 6543 The "Content-Range" header field is sent in a single part 206 6544 (Partial Content) response to indicate the partial range of the 6545 selected representation enclosed as the message content, sent in each 6546 part of a multipart 206 response to indicate the range enclosed 6547 within each body part, and sent in 416 (Range Not Satisfiable) 6548 responses to provide information about the selected representation. 6550 Content-Range = range-unit SP 6551 ( range-resp / unsatisfied-range ) 6553 range-resp = incl-range "/" ( complete-length / "*" ) 6554 incl-range = first-pos "-" last-pos 6555 unsatisfied-range = "*/" complete-length 6557 complete-length = 1*DIGIT 6559 If a 206 (Partial Content) response contains a Content-Range header 6560 field with a range unit (Section 14.1) that the recipient does not 6561 understand, the recipient MUST NOT attempt to recombine it with a 6562 stored representation. A proxy that receives such a message SHOULD 6563 forward it downstream. 6565 Content-Range might also be sent as a request modifier to request a 6566 partial PUT, as described in Section 14.5, based on private 6567 agreements between client and origin server. A server MUST ignore a 6568 Content-Range header field received in a request with a method for 6569 which Content-Range support is not defined. 6571 For byte ranges, a sender SHOULD indicate the complete length of the 6572 representation from which the range has been extracted, unless the 6573 complete length is unknown or difficult to determine. An asterisk 6574 character ("*") in place of the complete-length indicates that the 6575 representation length was unknown when the header field was 6576 generated. 6578 The following example illustrates when the complete length of the 6579 selected representation is known by the sender to be 1234 bytes: 6581 Content-Range: bytes 42-1233/1234 6582 and this second example illustrates when the complete length is 6583 unknown: 6585 Content-Range: bytes 42-1233/* 6587 A Content-Range field value is invalid if it contains a range-resp 6588 that has a last-pos value less than its first-pos value, or a 6589 complete-length value less than or equal to its last-pos value. The 6590 recipient of an invalid Content-Range MUST NOT attempt to recombine 6591 the received content with a stored representation. 6593 A server generating a 416 (Range Not Satisfiable) response to a byte- 6594 range request SHOULD send a Content-Range header field with an 6595 unsatisfied-range value, as in the following example: 6597 Content-Range: bytes */1234 6599 The complete-length in a 416 response indicates the current length of 6600 the selected representation. 6602 The Content-Range header field has no meaning for status codes that 6603 do not explicitly describe its semantic. For this specification, 6604 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status 6605 codes describe a meaning for Content-Range. 6607 The following are examples of Content-Range values in which the 6608 selected representation contains a total of 1234 bytes: 6610 * The first 500 bytes: 6612 Content-Range: bytes 0-499/1234 6614 * The second 500 bytes: 6616 Content-Range: bytes 500-999/1234 6618 * All except for the first 500 bytes: 6620 Content-Range: bytes 500-1233/1234 6622 * The last 500 bytes: 6624 Content-Range: bytes 734-1233/1234 6626 14.5. Partial PUT 6628 Some origin servers support PUT of a partial representation when the 6629 user agent sends a Content-Range header field (Section 14.4) in the 6630 request, though such support is inconsistent and depends on private 6631 agreements with user agents. In general, it requests that the state 6632 of the target resource be partly replaced with the enclosed content 6633 at an offset and length indicated by the Content-Range value, where 6634 the offset is relative to the current selected representation. 6636 An origin server SHOULD respond with a 400 (Bad Request) status code 6637 if it receives Content-Range on a PUT for a target resource that does 6638 not support partial PUT requests. 6640 Partial PUT is not backwards compatible with the original definition 6641 of PUT. It may result in the content being written as a complete 6642 replacement for the current representation. 6644 Partial resource updates are also possible by targeting a separately 6645 identified resource with state that overlaps or extends a portion of 6646 the larger resource, or by using a different method that has been 6647 specifically defined for partial updates (for example, the PATCH 6648 method defined in [RFC5789]). 6650 14.6. Media Type multipart/byteranges 6652 When a 206 (Partial Content) response message includes the content of 6653 multiple ranges, they are transmitted as body parts in a multipart 6654 message body ([RFC2046], Section 5.1) with the media type of 6655 "multipart/byteranges". 6657 The multipart/byteranges media type includes one or more body parts, 6658 each with its own Content-Type and Content-Range fields. The 6659 required boundary parameter specifies the boundary string used to 6660 separate each body part. 6662 Implementation Notes: 6664 1. Additional CRLFs might precede the first boundary string in the 6665 body. 6667 2. Although [RFC2046] permits the boundary string to be quoted, some 6668 existing implementations handle a quoted boundary string 6669 incorrectly. 6671 3. A number of clients and servers were coded to an early draft of 6672 the byteranges specification that used a media type of multipart/ 6673 x-byteranges , which is almost (but not quite) compatible with 6674 this type. 6676 Despite the name, the "multipart/byteranges" media type is not 6677 limited to byte ranges. The following example uses an "exampleunit" 6678 range unit: 6680 HTTP/1.1 206 Partial Content 6681 Date: Tue, 14 Nov 1995 06:25:24 GMT 6682 Last-Modified: Tue, 14 July 04:58:08 GMT 6683 Content-Length: 2331785 6684 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 6686 --THIS_STRING_SEPARATES 6687 Content-Type: video/example 6688 Content-Range: exampleunit 1.2-4.3/25 6690 ...the first range... 6691 --THIS_STRING_SEPARATES 6692 Content-Type: video/example 6693 Content-Range: exampleunit 11.2-14.3/25 6695 ...the second range 6696 --THIS_STRING_SEPARATES-- 6698 The following information serves as the registration form for the 6699 multipart/byteranges media type. 6701 Type name: multipart 6703 Subtype name: byteranges 6705 Required parameters: boundary 6707 Optional parameters: N/A 6709 Encoding considerations: only "7bit", "8bit", or "binary" are 6710 permitted 6712 Security considerations: see Section 17 6714 Interoperability considerations: N/A 6716 Published specification: This specification (see Section 14.6). 6718 Applications that use this media type: HTTP components supporting 6719 multiple ranges in a single request. 6721 Fragment identifier considerations: N/A 6723 Additional information: Deprecated alias names for this type: N/A 6725 Magic number(s): N/A 6727 File extension(s): N/A 6729 Macintosh file type code(s): N/A 6731 Person and email address to contact for further information: See Aut 6732 hors' Addresses section. 6734 Intended usage: COMMON 6736 Restrictions on usage: N/A 6738 Author: See Authors' Addresses section. 6740 Change controller: IESG 6742 15. Status Codes 6744 The status code of a response is a three-digit integer code that 6745 describes the result of the request and the semantics of the 6746 response, including whether the request was successful and what 6747 content is enclosed (if any). All valid status codes are within the 6748 range of 100 to 599, inclusive. 6750 The first digit of the status code defines the class of response. 6751 The last two digits do not have any categorization role. There are 6752 five values for the first digit: 6754 * 1xx (Informational): The request was received, continuing process 6756 * 2xx (Successful): The request was successfully received, 6757 understood, and accepted 6759 * 3xx (Redirection): Further action needs to be taken in order to 6760 complete the request 6762 * 4xx (Client Error): The request contains bad syntax or cannot be 6763 fulfilled 6765 * 5xx (Server Error): The server failed to fulfill an apparently 6766 valid request 6768 HTTP status codes are extensible. A client is not required to 6769 understand the meaning of all registered status codes, though such 6770 understanding is obviously desirable. However, a client MUST 6771 understand the class of any status code, as indicated by the first 6772 digit, and treat an unrecognized status code as being equivalent to 6773 the x00 status code of that class. 6775 For example, if a client receives an unrecognized status code of 471, 6776 it can see from the first digit that there was something wrong with 6777 its request and treat the response as if it had received a 400 (Bad 6778 Request) status code. The response message will usually contain a 6779 representation that explains the status. 6781 Values outside the range 100..599 are invalid. Implementations often 6782 use three-digit integer values outside of that range (i.e., 600..999) 6783 for internal communication of non-HTTP status (e.g., library errors). 6784 A client that receives a response with an invalid status code SHOULD 6785 process the response as if it had a 5xx (Server Error) status code. 6787 A single request can have multiple associated responses: zero or more 6788 _interim_ (non-final) responses with status codes in the 6789 "informational" (1xx) range, followed by exactly one _final_ response 6790 with a status code in one of the other ranges. 6792 15.1. Overview of Status Codes 6794 The status codes listed below are defined in this specification. The 6795 reason phrases listed here are only recommendations - they can be 6796 replaced by local equivalents or left out altogether without 6797 affecting the protocol. 6799 Responses with status codes that are defined as heuristically 6800 cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 6801 414, and 501 in this specification) can be reused by a cache with 6802 heuristic expiration unless otherwise indicated by the method 6803 definition or explicit cache controls [CACHING]; all other status 6804 codes are not heuristically cacheable. 6806 Additional status codes, outside the scope of this specification, 6807 have been specified for use in HTTP. All such status codes ought to 6808 be registered within the "Hypertext Transfer Protocol (HTTP) Status 6809 Code Registry", as described in Section 16.2. 6811 15.2. Informational 1xx 6813 The _1xx (Informational)_ class of status code indicates an interim 6814 response for communicating connection status or request progress 6815 prior to completing the requested action and sending a final 6816 response. Since HTTP/1.0 did not define any 1xx status codes, a 6817 server MUST NOT send a 1xx response to an HTTP/1.0 client. 6819 A 1xx response is terminated by the end of the header section; it 6820 cannot contain content or trailers. 6822 A client MUST be able to parse one or more 1xx responses received 6823 prior to a final response, even if the client does not expect one. A 6824 user agent MAY ignore unexpected 1xx responses. 6826 A proxy MUST forward 1xx responses unless the proxy itself requested 6827 the generation of the 1xx response. For example, if a proxy adds an 6828 "Expect: 100-continue" header field when it forwards a request, then 6829 it need not forward the corresponding 100 (Continue) response(s). 6831 15.2.1. 100 Continue 6833 The _100 (Continue)_ status code indicates that the initial part of a 6834 request has been received and has not yet been rejected by the 6835 server. The server intends to send a final response after the 6836 request has been fully received and acted upon. 6838 When the request contains an Expect header field that includes a 6839 100-continue expectation, the 100 response indicates that the server 6840 wishes to receive the request content, as described in 6841 Section 10.1.1. The client ought to continue sending the request and 6842 discard the 100 response. 6844 If the request did not contain an Expect header field containing the 6845 100-continue expectation, the client can simply discard this interim 6846 response. 6848 15.2.2. 101 Switching Protocols 6850 The _101 (Switching Protocols)_ status code indicates that the server 6851 understands and is willing to comply with the client's request, via 6852 the Upgrade header field (Section 7.8), for a change in the 6853 application protocol being used on this connection. The server MUST 6854 generate an Upgrade header field in the response that indicates which 6855 protocol(s) will be in effect after this response. 6857 It is assumed that the server will only agree to switch protocols 6858 when it is advantageous to do so. For example, switching to a newer 6859 version of HTTP might be advantageous over older versions, and 6860 switching to a real-time, synchronous protocol might be advantageous 6861 when delivering resources that use such features. 6863 15.3. Successful 2xx 6865 The _2xx (Successful)_ class of status code indicates that the 6866 client's request was successfully received, understood, and accepted. 6868 15.3.1. 200 OK 6870 The _200 (OK)_ status code indicates that the request has succeeded. 6871 The content sent in a 200 response depends on the request method. 6872 For the methods defined by this specification, the intended meaning 6873 of the content can be summarized as: 6875 +================+============================================+ 6876 | request method | response content is a representation of | 6877 +================+============================================+ 6878 | GET | the target resource | 6879 +----------------+--------------------------------------------+ 6880 | HEAD | the target resource, like GET, but without | 6881 | | transferring the representation data | 6882 +----------------+--------------------------------------------+ 6883 | POST | the status of, or results obtained from, | 6884 | | the action | 6885 +----------------+--------------------------------------------+ 6886 | PUT, DELETE | the status of the action | 6887 +----------------+--------------------------------------------+ 6888 | OPTIONS | communication options for the target | 6889 | | resource | 6890 +----------------+--------------------------------------------+ 6891 | TRACE | the request message as received by the | 6892 | | server returning the trace | 6893 +----------------+--------------------------------------------+ 6895 Table 6 6897 Aside from responses to CONNECT, a 200 response is expected to 6898 contain message content unless the message framing explicitly 6899 indicates that the content has zero length. If some aspect of the 6900 request indicates a preference for no content upon success, the 6901 origin server ought to send a _204 (No Content)_ response instead. 6902 For CONNECT, there is no content because the successful result is a 6903 tunnel, which begins immediately after the 200 response header 6904 section. 6906 A 200 response is heuristically cacheable; i.e., unless otherwise 6907 indicated by the method definition or explicit cache controls (see 6908 Section 4.2.2 of [CACHING]). 6910 15.3.2. 201 Created 6912 The _201 (Created)_ status code indicates that the request has been 6913 fulfilled and has resulted in one or more new resources being 6914 created. The primary resource created by the request is identified 6915 by either a Location header field in the response or, if no Location 6916 header field is received, by the target URI. 6918 The 201 response content typically describes and links to the 6919 resource(s) created. See Section 8.8 for a discussion of the meaning 6920 and purpose of validator fields, such as ETag and Last-Modified, in a 6921 201 response. 6923 15.3.3. 202 Accepted 6925 The _202 (Accepted)_ status code indicates that the request has been 6926 accepted for processing, but the processing has not been completed. 6927 The request might or might not eventually be acted upon, as it might 6928 be disallowed when processing actually takes place. There is no 6929 facility in HTTP for re-sending a status code from an asynchronous 6930 operation. 6932 The 202 response is intentionally noncommittal. Its purpose is to 6933 allow a server to accept a request for some other process (perhaps a 6934 batch-oriented process that is only run once per day) without 6935 requiring that the user agent's connection to the server persist 6936 until the process is completed. The representation sent with this 6937 response ought to describe the request's current status and point to 6938 (or embed) a status monitor that can provide the user with an 6939 estimate of when the request will be fulfilled. 6941 15.3.4. 203 Non-Authoritative Information 6943 The _203 (Non-Authoritative Information)_ status code indicates that 6944 the request was successful but the enclosed content has been modified 6945 from that of the origin server's 200 (OK) response by a transforming 6946 proxy (Section 7.7). This status code allows the proxy to notify 6947 recipients when a transformation has been applied, since that 6948 knowledge might impact later decisions regarding the content. For 6949 example, future cache validation requests for the content might only 6950 be applicable along the same request path (through the same proxies). 6952 A 203 response is heuristically cacheable; i.e., unless otherwise 6953 indicated by the method definition or explicit cache controls (see 6954 Section 4.2.2 of [CACHING]). 6956 15.3.5. 204 No Content 6958 The _204 (No Content)_ status code indicates that the server has 6959 successfully fulfilled the request and that there is no additional 6960 content to send in the response content. Metadata in the response 6961 header fields refer to the target resource and its selected 6962 representation after the requested action was applied. 6964 For example, if a 204 status code is received in response to a PUT 6965 request and the response contains an ETag field, then the PUT was 6966 successful and the ETag field value contains the entity-tag for the 6967 new representation of that target resource. 6969 The 204 response allows a server to indicate that the action has been 6970 successfully applied to the target resource, while implying that the 6971 user agent does not need to traverse away from its current "document 6972 view" (if any). The server assumes that the user agent will provide 6973 some indication of the success to its user, in accord with its own 6974 interface, and apply any new or updated metadata in the response to 6975 its active representation. 6977 For example, a 204 status code is commonly used with document editing 6978 interfaces corresponding to a "save" action, such that the document 6979 being saved remains available to the user for editing. It is also 6980 frequently used with interfaces that expect automated data transfers 6981 to be prevalent, such as within distributed version control systems. 6983 A 204 response is terminated by the end of the header section; it 6984 cannot contain content or trailers. 6986 A 204 response is heuristically cacheable; i.e., unless otherwise 6987 indicated by the method definition or explicit cache controls (see 6988 Section 4.2.2 of [CACHING]). 6990 15.3.6. 205 Reset Content 6992 The _205 (Reset Content)_ status code indicates that the server has 6993 fulfilled the request and desires that the user agent reset the 6994 "document view", which caused the request to be sent, to its original 6995 state as received from the origin server. 6997 This response is intended to support a common data entry use case 6998 where the user receives content that supports data entry (a form, 6999 notepad, canvas, etc.), enters or manipulates data in that space, 7000 causes the entered data to be submitted in a request, and then the 7001 data entry mechanism is reset for the next entry so that the user can 7002 easily initiate another input action. 7004 Since the 205 status code implies that no additional content will be 7005 provided, a server MUST NOT generate content in a 205 response. 7007 15.3.7. 206 Partial Content 7009 The _206 (Partial Content)_ status code indicates that the server is 7010 successfully fulfilling a range request for the target resource by 7011 transferring one or more parts of the selected representation. 7013 A server that supports range requests (Section 14) will usually 7014 attempt to satisfy all of the requested ranges, since sending less 7015 data will likely result in another client request for the remainder. 7016 However, a server might want to send only a subset of the data 7017 requested for reasons of its own, such as temporary unavailability, 7018 cache efficiency, load balancing, etc. Since a 206 response is self- 7019 descriptive, the client can still understand a response that only 7020 partially satisfies its range request. 7022 A client MUST inspect a 206 response's Content-Type and Content-Range 7023 field(s) to determine what parts are enclosed and whether additional 7024 requests are needed. 7026 A server that generates a 206 response MUST generate the following 7027 header fields, in addition to those required in the subsections 7028 below, if the field would have been sent in a 200 (OK) response to 7029 the same request: Date, Cache-Control, ETag, Expires, 7030 Content-Location, and Vary. 7032 A Content-Length header field present in a 206 response indicates the 7033 number of octets in the content of this message, which is usually not 7034 the complete length of the selected representation. Each 7035 Content-Range header field includes information about the selected 7036 representation's complete length. 7038 A sender that generates a 206 response to a request with an If-Range 7039 header field SHOULD NOT generate other representation header fields 7040 beyond those required, because the client already has a prior 7041 response containing those header fields. Otherwise, a sender MUST 7042 generate all of the representation header fields that would have been 7043 sent in a 200 (OK) response to the same request. 7045 A 206 response is heuristically cacheable; i.e., unless otherwise 7046 indicated by explicit cache controls (see Section 4.2.2 of 7047 [CACHING]). 7049 15.3.7.1. Single Part 7051 If a single part is being transferred, the server generating the 206 7052 response MUST generate a Content-Range header field, describing what 7053 range of the selected representation is enclosed, and a content 7054 consisting of the range. For example: 7056 HTTP/1.1 206 Partial Content 7057 Date: Wed, 15 Nov 1995 06:25:24 GMT 7058 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 7059 Content-Range: bytes 21010-47021/47022 7060 Content-Length: 26012 7061 Content-Type: image/gif 7063 ... 26012 bytes of partial image data ... 7065 15.3.7.2. Multiple Parts 7067 If multiple parts are being transferred, the server generating the 7068 206 response MUST generate "multipart/byteranges" content, as defined 7069 in Section 14.6, and a Content-Type header field containing the 7070 multipart/byteranges media type and its required boundary parameter. 7071 To avoid confusion with single-part responses, a server MUST NOT 7072 generate a Content-Range header field in the HTTP header section of a 7073 multiple part response (this field will be sent in each part 7074 instead). 7076 Within the header area of each body part in the multipart content, 7077 the server MUST generate a Content-Range header field corresponding 7078 to the range being enclosed in that body part. If the selected 7079 representation would have had a Content-Type header field in a 200 7080 (OK) response, the server SHOULD generate that same Content-Type 7081 header field in the header area of each body part. For example: 7083 HTTP/1.1 206 Partial Content 7084 Date: Wed, 15 Nov 1995 06:25:24 GMT 7085 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 7086 Content-Length: 1741 7087 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 7089 --THIS_STRING_SEPARATES 7090 Content-Type: application/pdf 7091 Content-Range: bytes 500-999/8000 7093 ...the first range... 7094 --THIS_STRING_SEPARATES 7095 Content-Type: application/pdf 7096 Content-Range: bytes 7000-7999/8000 7098 ...the second range 7099 --THIS_STRING_SEPARATES-- 7101 When multiple ranges are requested, a server MAY coalesce any of the 7102 ranges that overlap, or that are separated by a gap that is smaller 7103 than the overhead of sending multiple parts, regardless of the order 7104 in which the corresponding range-spec appeared in the received Range 7105 header field. Since the typical overhead between each part of a 7106 multipart/byteranges is around 80 bytes, depending on the selected 7107 representation's media type and the chosen boundary parameter length, 7108 it can be less efficient to transfer many small disjoint parts than 7109 it is to transfer the entire selected representation. 7111 A server MUST NOT generate a multipart response to a request for a 7112 single range, since a client that does not request multiple parts 7113 might not support multipart responses. However, a server MAY 7114 generate a multipart/byteranges response with only a single body part 7115 if multiple ranges were requested and only one range was found to be 7116 satisfiable or only one range remained after coalescing. A client 7117 that cannot process a multipart/byteranges response MUST NOT generate 7118 a request that asks for multiple ranges. 7120 A server that generates a multipart response SHOULD send the parts in 7121 the same order that the corresponding range-spec appeared in the 7122 received Range header field, excluding those ranges that were deemed 7123 unsatisfiable or that were coalesced into other ranges. A client 7124 that receives a multipart response MUST inspect the Content-Range 7125 header field present in each body part in order to determine which 7126 range is contained in that body part; a client cannot rely on 7127 receiving the same ranges that it requested, nor the same order that 7128 it requested. 7130 15.3.7.3. Combining Parts 7132 A response might transfer only a subrange of a representation if the 7133 connection closed prematurely or if the request used one or more 7134 Range specifications. After several such transfers, a client might 7135 have received several ranges of the same representation. These 7136 ranges can only be safely combined if they all have in common the 7137 same strong validator (Section 8.8.1). 7139 A client that has received multiple partial responses to GET requests 7140 on a target resource MAY combine those responses into a larger 7141 continuous range if they share the same strong validator. 7143 If the most recent response is an incomplete 200 (OK) response, then 7144 the header fields of that response are used for any combined response 7145 and replace those of the matching stored responses. 7147 If the most recent response is a 206 (Partial Content) response and 7148 at least one of the matching stored responses is a 200 (OK), then the 7149 combined response header fields consist of the most recent 200 7150 response's header fields. If all of the matching stored responses 7151 are 206 responses, then the stored response with the most recent 7152 header fields is used as the source of header fields for the combined 7153 response, except that the client MUST use other header fields 7154 provided in the new response, aside from Content-Range, to replace 7155 all instances of the corresponding header fields in the stored 7156 response. 7158 The combined response content consists of the union of partial 7159 content ranges in the new response and each of the selected 7160 responses. If the union consists of the entire range of the 7161 representation, then the client MUST process the combined response as 7162 if it were a complete 200 (OK) response, including a Content-Length 7163 header field that reflects the complete length. Otherwise, the 7164 client MUST process the set of continuous ranges as one of the 7165 following: an incomplete 200 (OK) response if the combined response 7166 is a prefix of the representation, a single 206 (Partial Content) 7167 response containing multipart/byteranges content, or multiple 206 7168 (Partial Content) responses, each with one continuous range that is 7169 indicated by a Content-Range header field. 7171 15.4. Redirection 3xx 7173 The _3xx (Redirection)_ class of status code indicates that further 7174 action needs to be taken by the user agent in order to fulfill the 7175 request. There are several types of redirects: 7177 1. Redirects that indicate this resource might be available at a 7178 different URI, as provided by the Location header field, as in 7179 the status codes 301 (Moved Permanently), 302 (Found), 307 7180 (Temporary Redirect), and 308 (Permanent Redirect). 7182 2. Redirection that offers a choice among matching resources capable 7183 of representing this resource, as in the 300 (Multiple Choices) 7184 status code. 7186 3. Redirection to a different resource, identified by the Location 7187 header field, that can represent an indirect response to the 7188 request, as in the 303 (See Other) status code. 7190 4. Redirection to a previously stored result, as in the 304 (Not 7191 Modified) status code. 7193 If a Location header field (Section 10.2.3) is provided, the user 7194 agent MAY automatically redirect its request to the URI referenced by 7195 the Location field value, even if the specific status code is not 7196 understood. Automatic redirection needs to be done with care for 7197 methods not known to be safe, as defined in Section 9.2.1, since the 7198 user might not wish to redirect an unsafe request. 7200 When automatically following a redirected request, the user agent 7201 SHOULD resend the original request message with the following 7202 modifications: 7204 1. Replace the target URI with the URI referenced by the redirection 7205 response's Location header field value after resolving it 7206 relative to the original request's target URI. 7208 2. Remove header fields that were automatically generated by the 7209 implementation, replacing them with updated values as appropriate 7210 to the new request. This includes: 7212 1. Connection-specific header fields (see Section 7.6.1), 7214 2. Header fields specific to the client's proxy configuration, 7215 including (but not limited to) Proxy-Authorization, 7217 3. Origin-specific header fields (if any), including (but not 7218 limited to) Host, 7220 4. Validating header fields that were added by the 7221 implementation's cache (e.g., If-None-Match, 7222 If-Modified-Since), 7224 5. Resource-specific header fields, including (but not limited 7225 to) Referer, Origin, Authorization, and Cookie. 7227 3. Consider removing header fields that were not automatically 7228 generated by the implementation (i.e., those present in the 7229 request because they were added by the calling context) where 7230 there are security implications; this includes but is not limited 7231 to Authorization and Cookie. 7233 4. Change the request method according to the redirecting status 7234 code's semantics, if applicable. 7236 5. If the request method has been changed to GET or HEAD, remove 7237 content-specific header fields, including (but not limited to) 7238 Content-Encoding, Content-Language, Content-Location, 7239 Content-Type, Content-Length, Digest, ETag, Last-Modified. 7241 | *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently) 7242 | and 302 (Found) were defined for the first type of redirect 7243 | ([HTTP/1.0], Section 9.3). Early user agents split on whether 7244 | the method applied to the redirect target would be the same as 7245 | the original request or would be rewritten as GET. Although 7246 | HTTP originally defined the former semantics for 301 and 302 7247 | (to match its original implementation at CERN), and defined 303 7248 | (See Other) to match the latter semantics, prevailing practice 7249 | gradually converged on the latter semantics for 301 and 302 as 7250 | well. The first revision of HTTP/1.1 added 307 (Temporary 7251 | Redirect) to indicate the former semantics of 302 without being 7252 | impacted by divergent practice. For the same reason, 308 7253 | (Permanent Redirect) was later on added in [RFC7538] to match 7254 | 301. Over 10 years later, most user agents still do method 7255 | rewriting for 301 and 302; therefore, [RFC7231] made that 7256 | behavior conformant when the original request is POST. 7258 A client SHOULD detect and intervene in cyclical redirections (i.e., 7259 "infinite" redirection loops). 7261 | *Note:* An earlier version of this specification recommended a 7262 | maximum of five redirections ([RFC2068], Section 10.3). 7263 | Content developers need to be aware that some clients might 7264 | implement such a fixed limitation. 7266 15.4.1. 300 Multiple Choices 7268 The _300 (Multiple Choices)_ status code indicates that the target 7269 resource has more than one representation, each with its own more 7270 specific identifier, and information about the alternatives is being 7271 provided so that the user (or user agent) can select a preferred 7272 representation by redirecting its request to one or more of those 7273 identifiers. In other words, the server desires that the user agent 7274 engage in reactive negotiation to select the most appropriate 7275 representation(s) for its needs (Section 12). 7277 If the server has a preferred choice, the server SHOULD generate a 7278 Location header field containing a preferred choice's URI reference. 7279 The user agent MAY use the Location field value for automatic 7280 redirection. 7282 For request methods other than HEAD, the server SHOULD generate 7283 content in the 300 response containing a list of representation 7284 metadata and URI reference(s) from which the user or user agent can 7285 choose the one most preferred. The user agent MAY make a selection 7286 from that list automatically if it understands the provided media 7287 type. A specific format for automatic selection is not defined by 7288 this specification because HTTP tries to remain orthogonal to the 7289 definition of its content. In practice, the representation is 7290 provided in some easily parsed format believed to be acceptable to 7291 the user agent, as determined by shared design or content 7292 negotiation, or in some commonly accepted hypertext format. 7294 A 300 response is heuristically cacheable; i.e., unless otherwise 7295 indicated by the method definition or explicit cache controls (see 7296 Section 4.2.2 of [CACHING]). 7298 | *Note:* The original proposal for the 300 status code defined 7299 | the URI header field as providing a list of alternative 7300 | representations, such that it would be usable for 200, 300, and 7301 | 406 responses and be transferred in responses to the HEAD 7302 | method. However, lack of deployment and disagreement over 7303 | syntax led to both URI and Alternates (a subsequent proposal) 7304 | being dropped from this specification. It is possible to 7305 | communicate the list as a Link header field value [RFC8288] 7306 | whose members have a relationship of "alternate", though 7307 | deployment is a chicken-and-egg problem. 7309 15.4.2. 301 Moved Permanently 7311 The _301 (Moved Permanently)_ status code indicates that the target 7312 resource has been assigned a new permanent URI and any future 7313 references to this resource ought to use one of the enclosed URIs. 7314 Clients with link-editing capabilities ought to automatically re-link 7315 references to the target URI to one or more of the new references 7316 sent by the server, where possible. 7318 The server SHOULD generate a Location header field in the response 7319 containing a preferred URI reference for the new permanent URI. The 7320 user agent MAY use the Location field value for automatic 7321 redirection. The server's response content usually contains a short 7322 hypertext note with a hyperlink to the new URI(s). 7324 | *Note:* For historical reasons, a user agent MAY change the 7325 | request method from POST to GET for the subsequent request. If 7326 | this behavior is undesired, the 308 (Permanent Redirect) status 7327 | code can be used instead. 7329 A 301 response is heuristically cacheable; i.e., unless otherwise 7330 indicated by the method definition or explicit cache controls (see 7331 Section 4.2.2 of [CACHING]). 7333 15.4.3. 302 Found 7335 The _302 (Found)_ status code indicates that the target resource 7336 resides temporarily under a different URI. Since the redirection 7337 might be altered on occasion, the client ought to continue to use the 7338 target URI for future requests. 7340 The server SHOULD generate a Location header field in the response 7341 containing a URI reference for the different URI. The user agent MAY 7342 use the Location field value for automatic redirection. The server's 7343 response content usually contains a short hypertext note with a 7344 hyperlink to the different URI(s). 7346 | *Note:* For historical reasons, a user agent MAY change the 7347 | request method from POST to GET for the subsequent request. If 7348 | this behavior is undesired, the 307 (Temporary Redirect) status 7349 | code can be used instead. 7351 15.4.4. 303 See Other 7353 The _303 (See Other)_ status code indicates that the server is 7354 redirecting the user agent to a different resource, as indicated by a 7355 URI in the Location header field, which is intended to provide an 7356 indirect response to the original request. A user agent can perform 7357 a retrieval request targeting that URI (a GET or HEAD request if 7358 using HTTP), which might also be redirected, and present the eventual 7359 result as an answer to the original request. Note that the new URI 7360 in the Location header field is not considered equivalent to the 7361 target URI. 7363 This status code is applicable to any HTTP method. It is primarily 7364 used to allow the output of a POST action to redirect the user agent 7365 to a selected resource, since doing so provides the information 7366 corresponding to the POST response in a form that can be separately 7367 identified, bookmarked, and cached, independent of the original 7368 request. 7370 A 303 response to a GET request indicates that the origin server does 7371 not have a representation of the target resource that can be 7372 transferred by the server over HTTP. However, the Location field 7373 value refers to a resource that is descriptive of the target 7374 resource, such that making a retrieval request on that other resource 7375 might result in a representation that is useful to recipients without 7376 implying that it represents the original target resource. Note that 7377 answers to the questions of what can be represented, what 7378 representations are adequate, and what might be a useful description 7379 are outside the scope of HTTP. 7381 Except for responses to a HEAD request, the representation of a 303 7382 response ought to contain a short hypertext note with a hyperlink to 7383 the same URI reference provided in the Location header field. 7385 15.4.5. 304 Not Modified 7387 The _304 (Not Modified)_ status code indicates that a conditional GET 7388 or HEAD request has been received and would have resulted in a 200 7389 (OK) response if it were not for the fact that the condition 7390 evaluated to false. In other words, there is no need for the server 7391 to transfer a representation of the target resource because the 7392 request indicates that the client, which made the request 7393 conditional, already has a valid representation; the server is 7394 therefore redirecting the client to make use of that stored 7395 representation as if it were the content of a 200 (OK) response. 7397 The server generating a 304 response MUST generate any of the 7398 following header fields that would have been sent in a 200 (OK) 7399 response to the same request: Cache-Control, Content-Location, Date, 7400 ETag, Expires, and Vary. 7402 Since the goal of a 304 response is to minimize information transfer 7403 when the recipient already has one or more cached representations, a 7404 sender SHOULD NOT generate representation metadata other than the 7405 above listed fields unless said metadata exists for the purpose of 7406 guiding cache updates (e.g., Last-Modified might be useful if the 7407 response does not have an ETag field). 7409 Requirements on a cache that receives a 304 response are defined in 7410 Section 4.3.4 of [CACHING]. If the conditional request originated 7411 with an outbound client, such as a user agent with its own cache 7412 sending a conditional GET to a shared proxy, then the proxy SHOULD 7413 forward the 304 response to that client. 7415 A 304 response is terminated by the end of the header section; it 7416 cannot contain content or trailers. 7418 15.4.6. 305 Use Proxy 7420 The _305 (Use Proxy)_ status code was defined in a previous version 7421 of this specification and is now deprecated (Appendix B of 7422 [RFC7231]). 7424 15.4.7. 306 (Unused) 7426 The 306 status code was defined in a previous version of this 7427 specification, is no longer used, and the code is reserved. 7429 15.4.8. 307 Temporary Redirect 7431 The _307 (Temporary Redirect)_ status code indicates that the target 7432 resource resides temporarily under a different URI and the user agent 7433 MUST NOT change the request method if it performs an automatic 7434 redirection to that URI. Since the redirection can change over time, 7435 the client ought to continue using the original target URI for future 7436 requests. 7438 The server SHOULD generate a Location header field in the response 7439 containing a URI reference for the different URI. The user agent MAY 7440 use the Location field value for automatic redirection. The server's 7441 response content usually contains a short hypertext note with a 7442 hyperlink to the different URI(s). 7444 15.4.9. 308 Permanent Redirect 7446 The _308 (Permanent Redirect)_ status code indicates that the target 7447 resource has been assigned a new permanent URI and any future 7448 references to this resource ought to use one of the enclosed URIs. 7449 Clients with link editing capabilities ought to automatically re-link 7450 references to the target URI to one or more of the new references 7451 sent by the server, where possible. 7453 The server SHOULD generate a Location header field in the response 7454 containing a preferred URI reference for the new permanent URI. The 7455 user agent MAY use the Location field value for automatic 7456 redirection. The server's response content usually contains a short 7457 hypertext note with a hyperlink to the new URI(s). 7459 A 308 response is heuristically cacheable; i.e., unless otherwise 7460 indicated by the method definition or explicit cache controls (see 7461 Section 4.2.2 of [CACHING]). 7463 | *Note:* This status code is much younger (June 2014) than its 7464 | sibling codes, and thus might not be recognized everywhere. 7465 | See Section 4 of [RFC7538] for deployment considerations. 7467 15.5. Client Error 4xx 7469 The _4xx (Client Error)_ class of status code indicates that the 7470 client seems to have erred. Except when responding to a HEAD 7471 request, the server SHOULD send a representation containing an 7472 explanation of the error situation, and whether it is a temporary or 7473 permanent condition. These status codes are applicable to any 7474 request method. User agents SHOULD display any included 7475 representation to the user. 7477 15.5.1. 400 Bad Request 7479 The _400 (Bad Request)_ status code indicates that the server cannot 7480 or will not process the request due to something that is perceived to 7481 be a client error (e.g., malformed request syntax, invalid request 7482 message framing, or deceptive request routing). 7484 15.5.2. 401 Unauthorized 7486 The _401 (Unauthorized)_ status code indicates that the request has 7487 not been applied because it lacks valid authentication credentials 7488 for the target resource. The server generating a 401 response MUST 7489 send a WWW-Authenticate header field (Section 11.6.1) containing at 7490 least one challenge applicable to the target resource. 7492 If the request included authentication credentials, then the 401 7493 response indicates that authorization has been refused for those 7494 credentials. The user agent MAY repeat the request with a new or 7495 replaced Authorization header field (Section 11.6.2). If the 401 7496 response contains the same challenge as the prior response, and the 7497 user agent has already attempted authentication at least once, then 7498 the user agent SHOULD present the enclosed representation to the 7499 user, since it usually contains relevant diagnostic information. 7501 15.5.3. 402 Payment Required 7503 The _402 (Payment Required)_ status code is reserved for future use. 7505 15.5.4. 403 Forbidden 7507 The _403 (Forbidden)_ status code indicates that the server 7508 understood the request but refuses to fulfill it. A server that 7509 wishes to make public why the request has been forbidden can describe 7510 that reason in the response content (if any). 7512 If authentication credentials were provided in the request, the 7513 server considers them insufficient to grant access. The client 7514 SHOULD NOT automatically repeat the request with the same 7515 credentials. The client MAY repeat the request with new or different 7516 credentials. However, a request might be forbidden for reasons 7517 unrelated to the credentials. 7519 An origin server that wishes to "hide" the current existence of a 7520 forbidden target resource MAY instead respond with a status code of 7521 404 (Not Found). 7523 15.5.5. 404 Not Found 7525 The _404 (Not Found)_ status code indicates that the origin server 7526 did not find a current representation for the target resource or is 7527 not willing to disclose that one exists. A 404 status code does not 7528 indicate whether this lack of representation is temporary or 7529 permanent; the 410 (Gone) status code is preferred over 404 if the 7530 origin server knows, presumably through some configurable means, that 7531 the condition is likely to be permanent. 7533 A 404 response is heuristically cacheable; i.e., unless otherwise 7534 indicated by the method definition or explicit cache controls (see 7535 Section 4.2.2 of [CACHING]). 7537 15.5.6. 405 Method Not Allowed 7539 The _405 (Method Not Allowed)_ status code indicates that the method 7540 received in the request-line is known by the origin server but not 7541 supported by the target resource. The origin server MUST generate an 7542 Allow header field in a 405 response containing a list of the target 7543 resource's currently supported methods. 7545 A 405 response is heuristically cacheable; i.e., unless otherwise 7546 indicated by the method definition or explicit cache controls (see 7547 Section 4.2.2 of [CACHING]). 7549 15.5.7. 406 Not Acceptable 7551 The _406 (Not Acceptable)_ status code indicates that the target 7552 resource does not have a current representation that would be 7553 acceptable to the user agent, according to the proactive negotiation 7554 header fields received in the request (Section 12.1), and the server 7555 is unwilling to supply a default representation. 7557 The server SHOULD generate content containing a list of available 7558 representation characteristics and corresponding resource identifiers 7559 from which the user or user agent can choose the one most 7560 appropriate. A user agent MAY automatically select the most 7561 appropriate choice from that list. However, this specification does 7562 not define any standard for such automatic selection, as described in 7563 Section 15.4.1. 7565 15.5.8. 407 Proxy Authentication Required 7567 The _407 (Proxy Authentication Required)_ status code is similar to 7568 401 (Unauthorized), but it indicates that the client needs to 7569 authenticate itself in order to use a proxy for this request. The 7570 proxy MUST send a Proxy-Authenticate header field (Section 11.7.1) 7571 containing a challenge applicable to that proxy for the request. The 7572 client MAY repeat the request with a new or replaced 7573 Proxy-Authorization header field (Section 11.7.2). 7575 15.5.9. 408 Request Timeout 7577 The _408 (Request Timeout)_ status code indicates that the server did 7578 not receive a complete request message within the time that it was 7579 prepared to wait. 7581 If the client has an outstanding request in transit, it MAY repeat 7582 that request. If the current connection is not usable (e.g., as it 7583 would be in HTTP/1.1, because request delimitation is lost), a new 7584 connection will be used. 7586 15.5.10. 409 Conflict 7588 The _409 (Conflict)_ status code indicates that the request could not 7589 be completed due to a conflict with the current state of the target 7590 resource. This code is used in situations where the user might be 7591 able to resolve the conflict and resubmit the request. The server 7592 SHOULD generate content that includes enough information for a user 7593 to recognize the source of the conflict. 7595 Conflicts are most likely to occur in response to a PUT request. For 7596 example, if versioning were being used and the representation being 7597 PUT included changes to a resource that conflict with those made by 7598 an earlier (third-party) request, the origin server might use a 409 7599 response to indicate that it can't complete the request. In this 7600 case, the response representation would likely contain information 7601 useful for merging the differences based on the revision history. 7603 15.5.11. 410 Gone 7605 The _410 (Gone)_ status code indicates that access to the target 7606 resource is no longer available at the origin server and that this 7607 condition is likely to be permanent. If the origin server does not 7608 know, or has no facility to determine, whether or not the condition 7609 is permanent, the status code 404 (Not Found) ought to be used 7610 instead. 7612 The 410 response is primarily intended to assist the task of web 7613 maintenance by notifying the recipient that the resource is 7614 intentionally unavailable and that the server owners desire that 7615 remote links to that resource be removed. Such an event is common 7616 for limited-time, promotional services and for resources belonging to 7617 individuals no longer associated with the origin server's site. It 7618 is not necessary to mark all permanently unavailable resources as 7619 "gone" or to keep the mark for any length of time - that is left to 7620 the discretion of the server owner. 7622 A 410 response is heuristically cacheable; i.e., unless otherwise 7623 indicated by the method definition or explicit cache controls (see 7624 Section 4.2.2 of [CACHING]). 7626 15.5.12. 411 Length Required 7628 The _411 (Length Required)_ status code indicates that the server 7629 refuses to accept the request without a defined Content-Length 7630 (Section 8.6). The client MAY repeat the request if it adds a valid 7631 Content-Length header field containing the length of the request 7632 content. 7634 15.5.13. 412 Precondition Failed 7636 The _412 (Precondition Failed)_ status code indicates that one or 7637 more conditions given in the request header fields evaluated to false 7638 when tested on the server (Section 13). This response status code 7639 allows the client to place preconditions on the current resource 7640 state (its current representations and metadata) and, thus, prevent 7641 the request method from being applied if the target resource is in an 7642 unexpected state. 7644 15.5.14. 413 Content Too Large 7646 The _413 (Content Too Large)_ status code indicates that the server 7647 is refusing to process a request because the request content is 7648 larger than the server is willing or able to process. The server MAY 7649 terminate the request, if the protocol version in use allows it; 7650 otherwise, the server MAY close the connection. 7652 If the condition is temporary, the server SHOULD generate a 7653 Retry-After header field to indicate that it is temporary and after 7654 what time the client MAY try again. 7656 15.5.15. 414 URI Too Long 7658 The _414 (URI Too Long)_ status code indicates that the server is 7659 refusing to service the request because the target URI is longer than 7660 the server is willing to interpret. This rare condition is only 7661 likely to occur when a client has improperly converted a POST request 7662 to a GET request with long query information, when the client has 7663 descended into a "black hole" of redirection (e.g., a redirected URI 7664 prefix that points to a suffix of itself) or when the server is under 7665 attack by a client attempting to exploit potential security holes. 7667 A 414 response is heuristically cacheable; i.e., unless otherwise 7668 indicated by the method definition or explicit cache controls (see 7669 Section 4.2.2 of [CACHING]). 7671 15.5.16. 415 Unsupported Media Type 7673 The _415 (Unsupported Media Type)_ status code indicates that the 7674 origin server is refusing to service the request because the content 7675 is in a format not supported by this method on the target resource. 7677 The format problem might be due to the request's indicated 7678 Content-Type or Content-Encoding, or as a result of inspecting the 7679 data directly. 7681 If the problem was caused by an unsupported content coding, the 7682 Accept-Encoding response header field (Section 12.5.3) ought to be 7683 used to indicate what (if any) content codings would have been 7684 accepted in the request. 7686 On the other hand, if the cause was an unsupported media type, the 7687 Accept response header field (Section 12.5.1) can be used to indicate 7688 what media types would have been accepted in the request. 7690 15.5.17. 416 Range Not Satisfiable 7692 The _416 (Range Not Satisfiable)_ status code indicates that the set 7693 of ranges in the request's Range header field (Section 14.2) has been 7694 rejected either because none of the requested ranges are satisfiable 7695 or because the client has requested an excessive number of small or 7696 overlapping ranges (a potential denial of service attack). 7698 Each range unit defines what is required for its own range sets to be 7699 satisfiable. For example, Section 14.1.2 defines what makes a bytes 7700 range set satisfiable. 7702 A server that generates a 416 response to a byte-range request SHOULD 7703 generate a Content-Range header field specifying the current length 7704 of the selected representation (Section 14.4). 7706 For example: 7708 HTTP/1.1 416 Range Not Satisfiable 7709 Date: Fri, 20 Jan 2012 15:41:54 GMT 7710 Content-Range: bytes */47022 7712 | *Note:* Because servers are free to ignore Range, many 7713 | implementations will respond with the entire selected 7714 | representation in a 200 (OK) response. That is partly because 7715 | most clients are prepared to receive a 200 (OK) to complete the 7716 | task (albeit less efficiently) and partly because clients might 7717 | not stop making an invalid range request until they have 7718 | received a complete representation. Thus, clients cannot 7719 | depend on receiving a 416 (Range Not Satisfiable) response even 7720 | when it is most appropriate. 7722 15.5.18. 417 Expectation Failed 7724 The _417 (Expectation Failed)_ status code indicates that the 7725 expectation given in the request's Expect header field 7726 (Section 10.1.1) could not be met by at least one of the inbound 7727 servers. 7729 15.5.19. 418 (Unused) 7731 [RFC2324] was an April 1 RFC that lampooned the various ways HTTP was 7732 abused; one such abuse was the definition of an application-specific 7733 418 status code. In the intervening years, this status code has been 7734 widely implemented as an "Easter Egg", and therefore is effectively 7735 consumed by this use. 7737 Therefore, the 418 status code is reserved in the IANA HTTP Status 7738 Code Registry. This indicates that the status code cannot be 7739 assigned to other applications currently. If future circumstances 7740 require its use (e.g., exhaustion of 4NN status codes), it can be re- 7741 assigned to another use. 7743 15.5.20. 421 Misdirected Request 7745 The 421 (Misdirected Request) status code indicates that the request 7746 was directed at a server that is unable or unwilling to produce an 7747 authoritative response for the target URI. An origin server (or 7748 gateway acting on behalf of the origin server) sends 421 to reject a 7749 target URI that does not match an origin for which the server has 7750 been configured (Section 4.3.1) or does not match the connection 7751 context over which the request was received (Section 7.4). 7753 A client that receives a 421 (Misdirected Request) response MAY retry 7754 the request, whether or not the request method is idempotent, over a 7755 different connection, such as a fresh connection specific to the 7756 target resource's origin, or via an alternative service [ALTSVC]. 7758 A proxy MUST NOT generate a 421 response. 7760 15.5.21. 422 Unprocessable Content 7762 The 422 (Unprocessable Content) status code indicates that the server 7763 understands the content type of the request content (hence a 415 7764 (Unsupported Media Type) status code is inappropriate), and the 7765 syntax of the request content is correct, but was unable to process 7766 the contained instructions. For example, this status code can be 7767 sent if an XML request content contains well-formed (i.e., 7768 syntactically correct), but semantically erroneous XML instructions. 7770 15.5.22. 426 Upgrade Required 7772 The _426 (Upgrade Required)_ status code indicates that the server 7773 refuses to perform the request using the current protocol but might 7774 be willing to do so after the client upgrades to a different 7775 protocol. The server MUST send an Upgrade header field in a 426 7776 response to indicate the required protocol(s) (Section 7.8). 7778 Example: 7780 HTTP/1.1 426 Upgrade Required 7781 Upgrade: HTTP/3.0 7782 Connection: Upgrade 7783 Content-Length: 53 7784 Content-Type: text/plain 7786 This service requires use of the HTTP/3.0 protocol. 7788 15.6. Server Error 5xx 7790 The _5xx (Server Error)_ class of status code indicates that the 7791 server is aware that it has erred or is incapable of performing the 7792 requested method. Except when responding to a HEAD request, the 7793 server SHOULD send a representation containing an explanation of the 7794 error situation, and whether it is a temporary or permanent 7795 condition. A user agent SHOULD display any included representation 7796 to the user. These response codes are applicable to any request 7797 method. 7799 15.6.1. 500 Internal Server Error 7801 The _500 (Internal Server Error)_ status code indicates that the 7802 server encountered an unexpected condition that prevented it from 7803 fulfilling the request. 7805 15.6.2. 501 Not Implemented 7807 The _501 (Not Implemented)_ status code indicates that the server 7808 does not support the functionality required to fulfill the request. 7809 This is the appropriate response when the server does not recognize 7810 the request method and is not capable of supporting it for any 7811 resource. 7813 A 501 response is heuristically cacheable; i.e., unless otherwise 7814 indicated by the method definition or explicit cache controls (see 7815 Section 4.2.2 of [CACHING]). 7817 15.6.3. 502 Bad Gateway 7819 The _502 (Bad Gateway)_ status code indicates that the server, while 7820 acting as a gateway or proxy, received an invalid response from an 7821 inbound server it accessed while attempting to fulfill the request. 7823 15.6.4. 503 Service Unavailable 7825 The _503 (Service Unavailable)_ status code indicates that the server 7826 is currently unable to handle the request due to a temporary overload 7827 or scheduled maintenance, which will likely be alleviated after some 7828 delay. The server MAY send a Retry-After header field 7829 (Section 10.2.4) to suggest an appropriate amount of time for the 7830 client to wait before retrying the request. 7832 | *Note:* The existence of the 503 status code does not imply 7833 | that a server has to use it when becoming overloaded. Some 7834 | servers might simply refuse the connection. 7836 15.6.5. 504 Gateway Timeout 7838 The _504 (Gateway Timeout)_ status code indicates that the server, 7839 while acting as a gateway or proxy, did not receive a timely response 7840 from an upstream server it needed to access in order to complete the 7841 request. 7843 15.6.6. 505 HTTP Version Not Supported 7845 The _505 (HTTP Version Not Supported)_ status code indicates that the 7846 server does not support, or refuses to support, the major version of 7847 HTTP that was used in the request message. The server is indicating 7848 that it is unable or unwilling to complete the request using the same 7849 major version as the client, as described in Section 2.5, other than 7850 with this error message. The server SHOULD generate a representation 7851 for the 505 response that describes why that version is not supported 7852 and what other protocols are supported by that server. 7854 16. Extending HTTP 7856 HTTP defines a number of generic extension points that can be used to 7857 introduce capabilities to the protocol without introducing a new 7858 version, including methods, status codes, field names, and further 7859 extensibility points within defined fields, such as authentication 7860 schemes and cache-directives (see Cache-Control extensions in 7861 Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not 7862 versioned, these extension points are persistent; the version of the 7863 protocol in use does not affect their semantics. 7865 Version-independent extensions are discouraged from depending on or 7866 interacting with the specific version of the protocol in use. When 7867 this is unavoidable, careful consideration needs to be given to how 7868 the extension can interoperate across versions. 7870 Additionally, specific versions of HTTP might have their own 7871 extensibility points, such as transfer-codings in HTTP/1.1 7872 (Section 6.1 of [HTTP/1.1]) and HTTP/2 ([HTTP/2]) SETTINGS or frame 7873 types. These extension points are specific to the version of the 7874 protocol they occur within. 7876 Version-specific extensions cannot override or modify the semantics 7877 of a version-independent mechanism or extension point (like a method 7878 or header field) without explicitly being allowed by that protocol 7879 element. For example, the CONNECT method (Section 9.3.6) allows 7880 this. 7882 These guidelines assure that the protocol operates correctly and 7883 predictably, even when parts of the path implement different versions 7884 of HTTP. 7886 16.1. Method Extensibility 7888 16.1.1. Method Registry 7890 The "Hypertext Transfer Protocol (HTTP) Method Registry", maintained 7891 by IANA at , registers 7892 method names. 7894 HTTP method registrations MUST include the following fields: 7896 * Method Name (see Section 9) 7898 * Safe ("yes" or "no", see Section 9.2.1) 7900 * Idempotent ("yes" or "no", see Section 9.2.2) 7902 * Pointer to specification text 7904 Values to be added to this namespace require IETF Review (see 7905 [RFC8126], Section 4.8). 7907 16.1.2. Considerations for New Methods 7909 Standardized methods are generic; that is, they are potentially 7910 applicable to any resource, not just one particular media type, kind 7911 of resource, or application. As such, it is preferred that new 7912 methods be registered in a document that isn't specific to a single 7913 application or data format, since orthogonal technologies deserve 7914 orthogonal specification. 7916 Since message parsing (Section 6) needs to be independent of method 7917 semantics (aside from responses to HEAD), definitions of new methods 7918 cannot change the parsing algorithm or prohibit the presence of 7919 content on either the request or the response message. Definitions 7920 of new methods can specify that only a zero-length content is allowed 7921 by requiring a Content-Length header field with a value of "0". 7923 Likewise, new methods cannot use the special host:port and asterisk 7924 forms of request target that are allowed for CONNECT and OPTIONS, 7925 respectively (Section 7.1). A full URI in absolute form is needed 7926 for the target URI, which means either the request target needs to be 7927 sent in absolute form or the target URI will be reconstructed from 7928 the request context in the same way it is for other methods. 7930 A new method definition needs to indicate whether it is safe 7931 (Section 9.2.1), idempotent (Section 9.2.2), cacheable 7932 (Section 9.2.3), what semantics are to be associated with the request 7933 content (if any), and what refinements the method makes to header 7934 field or status code semantics. If the new method is cacheable, its 7935 definition ought to describe how, and under what conditions, a cache 7936 can store a response and use it to satisfy a subsequent request. The 7937 new method ought to describe whether it can be made conditional 7938 (Section 13.1) and, if so, how a server responds when the condition 7939 is false. Likewise, if the new method might have some use for 7940 partial response semantics (Section 14.2), it ought to document this, 7941 too. 7943 | *Note:* Avoid defining a method name that starts with "M-", 7944 | since that prefix might be misinterpreted as having the 7945 | semantics assigned to it by [RFC2774]. 7947 16.2. Status Code Extensibility 7949 16.2.1. Status Code Registry 7951 The "Hypertext Transfer Protocol (HTTP) Status Code Registry", 7952 maintained by IANA at , registers status code numbers. 7955 A registration MUST include the following fields: 7957 * Status Code (3 digits) 7959 * Short Description 7961 * Pointer to specification text 7962 Values to be added to the HTTP status code namespace require IETF 7963 Review (see [RFC8126], Section 4.8). 7965 16.2.2. Considerations for New Status Codes 7967 When it is necessary to express semantics for a response that are not 7968 defined by current status codes, a new status code can be registered. 7969 Status codes are generic; they are potentially applicable to any 7970 resource, not just one particular media type, kind of resource, or 7971 application of HTTP. As such, it is preferred that new status codes 7972 be registered in a document that isn't specific to a single 7973 application. 7975 New status codes are required to fall under one of the categories 7976 defined in Section 15. To allow existing parsers to process the 7977 response message, new status codes cannot disallow content, although 7978 they can mandate a zero-length content. 7980 Proposals for new status codes that are not yet widely deployed ought 7981 to avoid allocating a specific number for the code until there is 7982 clear consensus that it will be registered; instead, early drafts can 7983 use a notation such as "4NN", or "3N0" .. "3N9", to indicate the 7984 class of the proposed status code(s) without consuming a number 7985 prematurely. 7987 The definition of a new status code ought to explain the request 7988 conditions that would cause a response containing that status code 7989 (e.g., combinations of request header fields and/or method(s)) along 7990 with any dependencies on response header fields (e.g., what fields 7991 are required, what fields can modify the semantics, and what field 7992 semantics are further refined when used with the new status code). 7994 By default, a status code applies only to the request corresponding 7995 to the response it occurs within. If a status code applies to a 7996 larger scope of applicability - for example, all requests to the 7997 resource in question, or all requests to a server - this must be 7998 explicitly specified. When doing so, it should be noted that not all 7999 clients can be expected to consistently apply a larger scope, because 8000 they might not understand the new status code. 8002 The definition of a new final status code ought to specify whether or 8003 not it is heuristically cacheable. Note that all final status codes 8004 can be cached if the response they occur in has explicit freshness 8005 information; however, those status codes that are defined as being 8006 heuristically cacheable are allowed to be cached without explicit 8007 freshness information. Likewise, the definition of a status code can 8008 place constraints upon cache behavior, if the 'must-understand' cache 8009 directive is used. See [CACHING] for more information. 8011 Finally, the definition of a new status code ought to indicate 8012 whether the content has any implied association with an identified 8013 resource (Section 6.4.2). 8015 16.3. Field Extensibility 8017 HTTP's most widely used extensibility point is the definition of new 8018 header and trailer fields. 8020 New fields can be defined such that, when they are understood by a 8021 recipient, they override or enhance the interpretation of previously 8022 defined fields, define preconditions on request evaluation, or refine 8023 the meaning of responses. 8025 However, defining a field doesn't guarantee its deployment or 8026 recognition by recipients. Most fields are designed with the 8027 expectation that a recipient can safely ignore (but forward 8028 downstream) any field not recognized. In other cases, the sender's 8029 ability to understand a given field might be indicated by its prior 8030 communication, perhaps in the protocol version or fields that it sent 8031 in prior messages, or its use of a specific media type. Likewise, 8032 direct inspection of support might be possible through an OPTIONS 8033 request or by interacting with a defined well-known URI [RFC8615] if 8034 such inspection is defined along with the field being introduced. 8036 16.3.1. Field Name Registry 8038 The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines 8039 the namespace for HTTP field names. 8041 Any party can request registration of an HTTP field. See 8042 Section 16.3.2 for considerations to take into account when creating 8043 a new HTTP field. 8045 The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is 8046 located at . 8047 Registration requests can be made by following the instructions 8048 located there or by sending an email to the "ietf-http-wg@w3.org" 8049 mailing list. 8051 Field names are registered on the advice of a Designated Expert 8052 (appointed by the IESG or their delegate). Fields with the status 8053 'permanent' are Specification Required ([RFC8126], Section 4.6). 8055 Registration requests consist of at least the following information: 8057 Field name: 8058 The requested field name. It MUST conform to the field-name 8059 syntax defined in Section 5.1, and SHOULD be restricted to just 8060 letters, digits, and hyphen ('-') characters, with the first 8061 character being a letter. 8063 Status: 8064 "permanent" or "provisional". 8066 Specification document(s): 8067 Reference to the document that specifies the field, preferably 8068 including a URI that can be used to retrieve a copy of the 8069 document. An indication of the relevant section(s) can also be 8070 included, but is not required. 8072 And, optionally: 8074 Comments: Additional information, such as about reserved entries. 8076 The Expert(s) can define additional fields to be collected in the 8077 registry, in consultation with the community. 8079 Standards-defined names have a status of "permanent". Other names 8080 can also be registered as permanent, if the Expert(s) find that they 8081 are in use, in consultation with the community. Other names should 8082 be registered as "provisional". 8084 Provisional entries can be removed by the Expert(s) if - in 8085 consultation with the community - the Expert(s) find that they are 8086 not in use. The Experts can change a provisional entry's status to 8087 permanent at any time. 8089 Note that names can be registered by third parties (including the 8090 Expert(s)), if the Expert(s) determines that an unregistered name is 8091 widely deployed and not likely to be registered in a timely manner 8092 otherwise. 8094 16.3.2. Considerations for New Fields 8096 HTTP header and trailer fields are a widely-used extension point for 8097 the protocol. While they can be used in an ad hoc fashion, fields 8098 that are intended for wider use need to be carefully documented to 8099 ensure interoperability. 8101 In particular, authors of specifications defining new fields are 8102 advised to consider and, where appropriate, document the following 8103 aspects: 8105 * Under what conditions the field can be used; e.g., only in 8106 responses or requests, in all messages, only on responses to a 8107 particular request method, etc. 8109 * Whether the field semantics are further refined by their context, 8110 such as their use with certain request methods or status codes. 8112 * The scope of applicability for the information conveyed. By 8113 default, fields apply only to the message they are associated 8114 with, but some response fields are designed to apply to all 8115 representations of a resource, the resource itself, or an even 8116 broader scope. Specifications that expand the scope of a response 8117 field will need to carefully consider issues such as content 8118 negotiation, the time period of applicability, and (in some cases) 8119 multi-tenant server deployments. 8121 * Under what conditions intermediaries are allowed to insert, 8122 delete, or modify the field's value. 8124 * If the field is allowable in trailers; by default, it will not be 8125 (see Section 6.5.1). 8127 * Whether it is appropriate or even required to list the field name 8128 in the Connection header field (i.e., if the field is to be hop- 8129 by-hop; see Section 7.6.1). 8131 * Whether the field introduces any additional security 8132 considerations, such as disclosure of privacy-related data. 8134 Request header fields have additional considerations that need to be 8135 documented if the default behaviour is not appropriate: 8137 * If it is appropriate to list the field name in a Vary response 8138 header field (e.g., when the request header field is used by an 8139 origin server's content selection algorithm; see Section 12.5.5). 8141 * If the field is intended to be stored when received in a PUT 8142 request (see Section 9.3.4). 8144 * If the field ought to be removed when automatically redirecting a 8145 request, due to security concerns (see Section 15.4). 8147 16.3.2.1. Considerations for New Field Names 8149 Authors of specifications defining new fields are advised to choose a 8150 short but descriptive field name. Short names avoid needless data 8151 transmission; descriptive names avoid confusion and "squatting" on 8152 names that might have broader uses. 8154 To that end, limited-use fields (such as a header confined to a 8155 single application or use case) are encouraged to use a name that 8156 includes that use (or an abbreviation) as a prefix; for example, if 8157 the Foo Application needs a Description field, it might use "Foo- 8158 Desc"; "Description" is too generic, and "Foo-Description" is 8159 needlessly long. 8161 While the field-name syntax is defined to allow any token character, 8162 in practice some implementations place limits on the characters they 8163 accept in field-names. To be interoperable, new field names SHOULD 8164 constrain themselves to alphanumeric characters, "-", and ".", and 8165 SHOULD begin with a letter. For example, the underscore ("_") 8166 character can be problematic when passed through non-HTTP gateway 8167 interfaces (see Section 17.10). 8169 Field names ought not be prefixed with "X-"; see [BCP178] for further 8170 information. 8172 Other prefixes are sometimes used in HTTP field names; for example, 8173 "Accept-" is used in many content negotiation headers, and "Content-" 8174 is used as explained in Section 6.4. These prefixes are only an aid 8175 to recognizing the purpose of a field, and do not trigger automatic 8176 processing. 8178 16.3.2.2. Considerations for New Field Values 8180 A major task in the definition of a new HTTP field is the 8181 specification of the field value syntax: what senders should 8182 generate, and how recipients should infer semantics from what is 8183 received. 8185 Authors are encouraged (but not required) to use either the ABNF 8186 rules in this specification or those in [RFC8941] to define the 8187 syntax of new field values. 8189 Authors are advised to carefully consider how the combination of 8190 multiple field lines will impact them (see Section 5.3). Because 8191 senders might erroneously send multiple values, and both 8192 intermediaries and HTTP libraries can perform combination 8193 automatically, this applies to all field values - even when only a 8194 single value is anticipated. 8196 Therefore, authors are advised to delimit or encode values that 8197 contain commas (e.g., with the quoted-string rule of Section 5.6.4, 8198 the String data type of [RFC8941], or a field-specific encoding). 8199 This ensures that commas within field data are not confused with the 8200 commas that delimit a list value. 8202 For example, the Content-Type field value only allows commas inside 8203 quoted strings, which can be reliably parsed even when multiple 8204 values are present. The Location field value provides a counter- 8205 example that should not be emulated: because URIs can include commas, 8206 it is not possible to reliably distinguish between a single value 8207 that includes a comma from two values. 8209 Authors of fields with a singleton value (see Section 5.5) are 8210 additionally advised to document how to treat messages where the 8211 multiple members are present (a sensible default would be to ignore 8212 the field, but this might not always be the right choice). 8214 16.4. Authentication Scheme Extensibility 8216 16.4.1. Authentication Scheme Registry 8218 The "Hypertext Transfer Protocol (HTTP) Authentication Scheme 8219 Registry" defines the namespace for the authentication schemes in 8220 challenges and credentials. It is maintained at 8221 . 8223 Registrations MUST include the following fields: 8225 * Authentication Scheme Name 8227 * Pointer to specification text 8229 * Notes (optional) 8231 Values to be added to this namespace require IETF Review (see 8232 [RFC8126], Section 4.8). 8234 16.4.2. Considerations for New Authentication Schemes 8236 There are certain aspects of the HTTP Authentication framework that 8237 put constraints on how new authentication schemes can work: 8239 * HTTP authentication is presumed to be stateless: all of the 8240 information necessary to authenticate a request MUST be provided 8241 in the request, rather than be dependent on the server remembering 8242 prior requests. Authentication based on, or bound to, the 8243 underlying connection is outside the scope of this specification 8244 and inherently flawed unless steps are taken to ensure that the 8245 connection cannot be used by any party other than the 8246 authenticated user (see Section 3.3). 8248 * The authentication parameter "realm" is reserved for defining 8249 protection spaces as described in Section 11.5. New schemes MUST 8250 NOT use it in a way incompatible with that definition. 8252 * The "token68" notation was introduced for compatibility with 8253 existing authentication schemes and can only be used once per 8254 challenge or credential. Thus, new schemes ought to use the auth- 8255 param syntax instead, because otherwise future extensions will be 8256 impossible. 8258 * The parsing of challenges and credentials is defined by this 8259 specification and cannot be modified by new authentication 8260 schemes. When the auth-param syntax is used, all parameters ought 8261 to support both token and quoted-string syntax, and syntactical 8262 constraints ought to be defined on the field value after parsing 8263 (i.e., quoted-string processing). This is necessary so that 8264 recipients can use a generic parser that applies to all 8265 authentication schemes. 8267 *Note:* The fact that the value syntax for the "realm" parameter 8268 is restricted to quoted-string was a bad design choice not to be 8269 repeated for new parameters. 8271 * Definitions of new schemes ought to define the treatment of 8272 unknown extension parameters. In general, a "must-ignore" rule is 8273 preferable to a "must-understand" rule, because otherwise it will 8274 be hard to introduce new parameters in the presence of legacy 8275 recipients. Furthermore, it's good to describe the policy for 8276 defining new parameters (such as "update the specification" or 8277 "use this registry"). 8279 * Authentication schemes need to document whether they are usable in 8280 origin-server authentication (i.e., using WWW-Authenticate), and/ 8281 or proxy authentication (i.e., using Proxy-Authenticate). 8283 * The credentials carried in an Authorization header field are 8284 specific to the user agent and, therefore, have the same effect on 8285 HTTP caches as the "private" Cache-Control response directive 8286 (Section 5.2.2.7 of [CACHING]), within the scope of the request in 8287 which they appear. 8289 Therefore, new authentication schemes that choose not to carry 8290 credentials in the Authorization header field (e.g., using a newly 8291 defined header field) will need to explicitly disallow caching, by 8292 mandating the use of Cache-Control response directives (e.g., 8293 "private"). 8295 * Schemes using Authentication-Info, Proxy-Authentication-Info, or 8296 any other authentication related response header field need to 8297 consider and document the related security considerations (see 8298 Section 17.16.4). 8300 16.5. Range Unit Extensibility 8302 16.5.1. Range Unit Registry 8304 The "HTTP Range Unit Registry" defines the namespace for the range 8305 unit names and refers to their corresponding specifications. It is 8306 maintained at . 8308 Registration of an HTTP Range Unit MUST include the following fields: 8310 * Name 8312 * Description 8314 * Pointer to specification text 8316 Values to be added to this namespace require IETF Review (see 8317 [RFC8126], Section 4.8). 8319 16.5.2. Considerations for New Range Units 8321 Other range units, such as format-specific boundaries like pages, 8322 sections, records, rows, or time, are potentially usable in HTTP for 8323 application-specific purposes, but are not commonly used in practice. 8324 Implementors of alternative range units ought to consider how they 8325 would work with content codings and general-purpose intermediaries. 8327 16.6. Content Coding Extensibility 8329 16.6.1. Content Coding Registry 8331 The "HTTP Content Coding Registry", maintained by IANA at 8332 , registers 8333 content-coding names. 8335 Content coding registrations MUST include the following fields: 8337 * Name 8339 * Description 8341 * Pointer to specification text 8342 Names of content codings MUST NOT overlap with names of transfer 8343 codings (as per the "HTTP Transfer Coding registry", located at 8344 ), unless the 8345 encoding transformation is identical (as is the case for the 8346 compression codings defined in Section 8.4.1). 8348 Values to be added to this namespace require IETF Review (see 8349 Section 4.8 of [RFC8126]) and MUST conform to the purpose of content 8350 coding defined in Section 8.4.1. 8352 16.6.2. Considerations for New Content Codings 8354 New content codings ought to be self-descriptive whenever possible, 8355 with optional parameters discoverable within the coding format 8356 itself, rather than rely on external metadata that might be lost 8357 during transit. 8359 16.7. Upgrade Token Registry 8361 The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" 8362 defines the namespace for protocol-name tokens used to identify 8363 protocols in the Upgrade header field. The registry is maintained at 8364 . 8366 Each registered protocol name is associated with contact information 8367 and an optional set of specifications that details how the connection 8368 will be processed after it has been upgraded. 8370 Registrations happen on a "First Come First Served" basis (see 8371 Section 4.4 of [RFC8126]) and are subject to the following rules: 8373 1. A protocol-name token, once registered, stays registered forever. 8375 2. A protocol-name token is case-insensitive and registered with the 8376 preferred case to be generated by senders. 8378 3. The registration MUST name a responsible party for the 8379 registration. 8381 4. The registration MUST name a point of contact. 8383 5. The registration MAY name a set of specifications associated with 8384 that token. Such specifications need not be publicly available. 8386 6. The registration SHOULD name a set of expected "protocol-version" 8387 tokens associated with that token at the time of registration. 8389 7. The responsible party MAY change the registration at any time. 8390 The IANA will keep a record of all such changes, and make them 8391 available upon request. 8393 8. The IESG MAY reassign responsibility for a protocol token. This 8394 will normally only be used in the case when a responsible party 8395 cannot be contacted. 8397 17. Security Considerations 8399 This section is meant to inform developers, information providers, 8400 and users of known security concerns relevant to HTTP semantics and 8401 its use for transferring information over the Internet. 8402 Considerations related to caching are discussed in Section 7 of 8403 [CACHING] and considerations related to HTTP/1.1 message syntax and 8404 parsing are discussed in Section 11 of [HTTP/1.1]. 8406 The list of considerations below is not exhaustive. Most security 8407 concerns related to HTTP semantics are about securing server-side 8408 applications (code behind the HTTP interface), securing user agent 8409 processing of content received via HTTP, or secure use of the 8410 Internet in general, rather than security of the protocol. Various 8411 organizations maintain topical information and links to current 8412 research on Web application security (e.g., [OWASP]). 8414 17.1. Establishing Authority 8416 HTTP relies on the notion of an _authoritative response_: a response 8417 that has been determined by (or at the direction of) the origin 8418 server identified within the target URI to be the most appropriate 8419 response for that request given the state of the target resource at 8420 the time of response message origination. 8422 When a registered name is used in the authority component, the "http" 8423 URI scheme (Section 4.2.1) relies on the user's local name resolution 8424 service to determine where it can find authoritative responses. This 8425 means that any attack on a user's network host table, cached names, 8426 or name resolution libraries becomes an avenue for attack on 8427 establishing authority for "http" URIs. Likewise, the user's choice 8428 of server for Domain Name Service (DNS), and the hierarchy of servers 8429 from which it obtains resolution results, could impact the 8430 authenticity of address mappings; DNS Security Extensions (DNSSEC, 8431 [RFC4033]) are one way to improve authenticity, as are the various 8432 mechanisms for making DNS requests over more secure transfer 8433 protocols. 8435 Furthermore, after an IP address is obtained, establishing authority 8436 for an "http" URI is vulnerable to attacks on Internet Protocol 8437 routing. 8439 The "https" scheme (Section 4.2.2) is intended to prevent (or at 8440 least reveal) many of these potential attacks on establishing 8441 authority, provided that the negotiated connection is secured and the 8442 client properly verifies that the communicating server's identity 8443 matches the target URI's authority component (Section 4.3.4). 8444 Correctly implementing such verification can be difficult (see 8445 [Georgiev]). 8447 Authority for a given origin server can be delegated through protocol 8448 extensions; for example, [ALTSVC]. Likewise, the set of servers for 8449 which a connection is considered authoritative can be changed with a 8450 protocol extension like [RFC8336]. 8452 Providing a response from a non-authoritative source, such as a 8453 shared proxy cache, is often useful to improve performance and 8454 availability, but only to the extent that the source can be trusted 8455 or the distrusted response can be safely used. 8457 Unfortunately, communicating authority to users can be difficult. 8458 For example, _phishing_ is an attack on the user's perception of 8459 authority, where that perception can be misled by presenting similar 8460 branding in hypertext, possibly aided by userinfo obfuscating the 8461 authority component (see Section 4.2.1). User agents can reduce the 8462 impact of phishing attacks by enabling users to easily inspect a 8463 target URI prior to making an action, by prominently distinguishing 8464 (or rejecting) userinfo when present, and by not sending stored 8465 credentials and cookies when the referring document is from an 8466 unknown or untrusted source. 8468 17.2. Risks of Intermediaries 8470 HTTP intermediaries are inherently situated for on-path attacks. 8471 Compromise of the systems on which the intermediaries run can result 8472 in serious security and privacy problems. Intermediaries might have 8473 access to security-related information, personal information about 8474 individual users and organizations, and proprietary information 8475 belonging to users and content providers. A compromised 8476 intermediary, or an intermediary implemented or configured without 8477 regard to security and privacy considerations, might be used in the 8478 commission of a wide range of potential attacks. 8480 Intermediaries that contain a shared cache are especially vulnerable 8481 to cache poisoning attacks, as described in Section 7 of [CACHING]. 8483 Implementers need to consider the privacy and security implications 8484 of their design and coding decisions, and of the configuration 8485 options they provide to operators (especially the default 8486 configuration). 8488 Intermediaries are no more trustworthy than the people and policies 8489 under which they operate; HTTP cannot solve this problem. 8491 17.3. Attacks Based on File and Path Names 8493 Origin servers frequently make use of their local file system to 8494 manage the mapping from target URI to resource representations. Most 8495 file systems are not designed to protect against malicious file or 8496 path names. Therefore, an origin server needs to avoid accessing 8497 names that have a special significance to the system when mapping the 8498 target resource to files, folders, or directories. 8500 For example, UNIX, Microsoft Windows, and other operating systems use 8501 ".." as a path component to indicate a directory level above the 8502 current one, and they use specially named paths or file names to send 8503 data to system devices. Similar naming conventions might exist 8504 within other types of storage systems. Likewise, local storage 8505 systems have an annoying tendency to prefer user-friendliness over 8506 security when handling invalid or unexpected characters, 8507 recomposition of decomposed characters, and case-normalization of 8508 case-insensitive names. 8510 Attacks based on such special names tend to focus on either denial- 8511 of-service (e.g., telling the server to read from a COM port) or 8512 disclosure of configuration and source files that are not meant to be 8513 served. 8515 17.4. Attacks Based on Command, Code, or Query Injection 8517 Origin servers often use parameters within the URI as a means of 8518 identifying system services, selecting database entries, or choosing 8519 a data source. However, data received in a request cannot be 8520 trusted. An attacker could construct any of the request data 8521 elements (method, target URI, header fields, or content) to contain 8522 data that might be misinterpreted as a command, code, or query when 8523 passed through a command invocation, language interpreter, or 8524 database interface. 8526 For example, SQL injection is a common attack wherein additional 8527 query language is inserted within some part of the target URI or 8528 header fields (e.g., Host, Referer, etc.). If the received data is 8529 used directly within a SELECT statement, the query language might be 8530 interpreted as a database command instead of a simple string value. 8531 This type of implementation vulnerability is extremely common, in 8532 spite of being easy to prevent. 8534 In general, resource implementations ought to avoid use of request 8535 data in contexts that are processed or interpreted as instructions. 8536 Parameters ought to be compared to fixed strings and acted upon as a 8537 result of that comparison, rather than passed through an interface 8538 that is not prepared for untrusted data. Received data that isn't 8539 based on fixed parameters ought to be carefully filtered or encoded 8540 to avoid being misinterpreted. 8542 Similar considerations apply to request data when it is stored and 8543 later processed, such as within log files, monitoring tools, or when 8544 included within a data format that allows embedded scripts. 8546 17.5. Attacks via Protocol Element Length 8548 Because HTTP uses mostly textual, character-delimited fields, parsers 8549 are often vulnerable to attacks based on sending very long (or very 8550 slow) streams of data, particularly where an implementation is 8551 expecting a protocol element with no predefined length (Section 2.3). 8553 To promote interoperability, specific recommendations are made for 8554 minimum size limits on fields (Section 5.4). These are minimum 8555 recommendations, chosen to be supportable even by implementations 8556 with limited resources; it is expected that most implementations will 8557 choose substantially higher limits. 8559 A server can reject a message that has a target URI that is too long 8560 (Section 15.5.15) or request content that is too large 8561 (Section 15.5.14). Additional status codes related to capacity 8562 limits have been defined by extensions to HTTP [RFC6585]. 8564 Recipients ought to carefully limit the extent to which they process 8565 other protocol elements, including (but not limited to) request 8566 methods, response status phrases, field names, numeric values, and 8567 chunk lengths. Failure to limit such processing can result in 8568 arbitrary code execution due to buffer or arithmetic overflows, and 8569 increased vulnerability to denial-of-service attacks. 8571 17.6. Attacks using Shared-dictionary Compression 8573 Some attacks on encrypted protocols use the differences in size 8574 created by dynamic compression to reveal confidential information; 8575 for example, [BREACH]. These attacks rely on creating a redundancy 8576 between attacker-controlled content and the confidential information, 8577 such that a dynamic compression algorithm using the same dictionary 8578 for both content will compress more efficiently when the attacker- 8579 controlled content matches parts of the confidential content. 8581 HTTP messages can be compressed in a number of ways, including using 8582 TLS compression, content codings, transfer codings, and other 8583 extension or version-specific mechanisms. 8585 The most effective mitigation for this risk is to disable compression 8586 on sensitive data, or to strictly separate sensitive data from 8587 attacker-controlled data so that they cannot share the same 8588 compression dictionary. With careful design, a compression scheme 8589 can be designed in a way that is not considered exploitable in 8590 limited use cases, such as HPACK ([HPACK]). 8592 17.7. Disclosure of Personal Information 8594 Clients are often privy to large amounts of personal information, 8595 including both information provided by the user to interact with 8596 resources (e.g., the user's name, location, mail address, passwords, 8597 encryption keys, etc.) and information about the user's browsing 8598 activity over time (e.g., history, bookmarks, etc.). Implementations 8599 need to prevent unintentional disclosure of personal information. 8601 17.8. Privacy of Server Log Information 8603 A server is in the position to save personal data about a user's 8604 requests over time, which might identify their reading patterns or 8605 subjects of interest. In particular, log information gathered at an 8606 intermediary often contains a history of user agent interaction, 8607 across a multitude of sites, that can be traced to individual users. 8609 HTTP log information is confidential in nature; its handling is often 8610 constrained by laws and regulations. Log information needs to be 8611 securely stored and appropriate guidelines followed for its analysis. 8612 Anonymization of personal information within individual entries 8613 helps, but it is generally not sufficient to prevent real log traces 8614 from being re-identified based on correlation with other access 8615 characteristics. As such, access traces that are keyed to a specific 8616 client are unsafe to publish even if the key is pseudonymous. 8618 To minimize the risk of theft or accidental publication, log 8619 information ought to be purged of personally identifiable 8620 information, including user identifiers, IP addresses, and user- 8621 provided query parameters, as soon as that information is no longer 8622 necessary to support operational needs for security, auditing, or 8623 fraud control. 8625 17.9. Disclosure of Sensitive Information in URIs 8627 URIs are intended to be shared, not secured, even when they identify 8628 secure resources. URIs are often shown on displays, added to 8629 templates when a page is printed, and stored in a variety of 8630 unprotected bookmark lists. Many servers, proxies, and user agents 8631 log or display the target URI in places where it might be visible to 8632 third parties. It is therefore unwise to include information within 8633 a URI that is sensitive, personally identifiable, or a risk to 8634 disclose. 8636 When an application uses client-side mechanisms to construct a target 8637 URI out of user-provided information, such as the query fields of a 8638 form using GET, potentially sensitive data might be provided that 8639 would not be appropriate for disclosure within a URI. POST is often 8640 preferred in such cases because it usually doesn't construct a URI; 8641 instead, POST of a form transmits the potentially sensitive data in 8642 the request content. However, this hinders caching and uses an 8643 unsafe method for what would otherwise be a safe request. 8644 Alternative workarounds include transforming the user-provided data 8645 prior to constructing the URI, or filtering the data to only include 8646 common values that are not sensitive. Likewise, redirecting the 8647 result of a query to a different (server-generated) URI can remove 8648 potentially sensitive data from later links and provide a cacheable 8649 response for later reuse. 8651 Since the Referer header field tells a target site about the context 8652 that resulted in a request, it has the potential to reveal 8653 information about the user's immediate browsing history and any 8654 personal information that might be found in the referring resource's 8655 URI. Limitations on the Referer header field are described in 8656 Section 10.1.3 to address some of its security considerations. 8658 17.10. Application Handling of Field Names 8660 Servers often use non-HTTP gateway interfaces and frameworks to 8661 process a received request and produce content for the response. For 8662 historical reasons, such interfaces often pass received field names 8663 as external variable names, using a name mapping suitable for 8664 environment variables. 8666 For example, the Common Gateway Interface (CGI) mapping of protocol- 8667 specific meta-variables, defined by Section 4.1.18 of [RFC3875], is 8668 applied to received header fields that do not correspond to one of 8669 CGI's standard variables; the mapping consists of prepending "HTTP_" 8670 to each name and changing all instances of hyphen ("-") to underscore 8671 ("_"). This same mapping has been inherited by many other 8672 application frameworks in order to simplify moving applications from 8673 one platform to the next. 8675 In CGI, a received Content-Length field would be passed as the meta- 8676 variable "CONTENT_LENGTH" with a string value matching the received 8677 field's value. In contrast, a received "Content_Length" header field 8678 would be passed as the protocol-specific meta-variable 8679 "HTTP_CONTENT_LENGTH", which might lead to some confusion if an 8680 application mistakenly reads the protocol-specific meta-variable 8681 instead of the default one. (This historical practice is why 8682 Section 16.3.2.1 discourages the creation of new field names that 8683 contain an underscore.) 8685 Unfortunately, mapping field names to different interface names can 8686 lead to security vulnerabilities if the mapping is incomplete or 8687 ambiguous. For example, if an attacker were to send a field named 8688 "Transfer_Encoding", a naive interface might map that to the same 8689 variable name as the "Transfer-Encoding" field, resulting in a 8690 potential request smuggling vulnerability (Section 11.2 of 8691 [HTTP/1.1]). 8693 To mitigate the associated risks, implementations that perform such 8694 mappings are advised to make the mapping unambiguous and complete for 8695 the full range of potential octets received as a name (including 8696 those that are discouraged or forbidden by the HTTP grammar). For 8697 example, a field with an unusual name character might result in the 8698 request being blocked, the specific field being removed, or the name 8699 being passed with a different prefix to distinguish it from other 8700 fields. 8702 17.11. Disclosure of Fragment after Redirects 8704 Although fragment identifiers used within URI references are not sent 8705 in requests, implementers ought to be aware that they will be visible 8706 to the user agent and any extensions or scripts running as a result 8707 of the response. In particular, when a redirect occurs and the 8708 original request's fragment identifier is inherited by the new 8709 reference in Location (Section 10.2.3), this might have the effect of 8710 disclosing one site's fragment to another site. If the first site 8711 uses personal information in fragments, it ought to ensure that 8712 redirects to other sites include a (possibly empty) fragment 8713 component in order to block that inheritance. 8715 17.12. Disclosure of Product Information 8717 The User-Agent (Section 10.1.6), Via (Section 7.6.3), and Server 8718 (Section 10.2.5) header fields often reveal information about the 8719 respective sender's software systems. In theory, this can make it 8720 easier for an attacker to exploit known security holes; in practice, 8721 attackers tend to try all potential holes regardless of the apparent 8722 software versions being used. 8724 Proxies that serve as a portal through a network firewall ought to 8725 take special precautions regarding the transfer of header information 8726 that might identify hosts behind the firewall. The Via header field 8727 allows intermediaries to replace sensitive machine names with 8728 pseudonyms. 8730 17.13. Browser Fingerprinting 8732 Browser fingerprinting is a set of techniques for identifying a 8733 specific user agent over time through its unique set of 8734 characteristics. These characteristics might include information 8735 related to how it uses the underlying transport protocol, feature 8736 capabilities, and scripting environment, though of particular 8737 interest here is the set of unique characteristics that might be 8738 communicated via HTTP. Fingerprinting is considered a privacy 8739 concern because it enables tracking of a user agent's behavior over 8740 time ([Bujlow]) without the corresponding controls that the user 8741 might have over other forms of data collection (e.g., cookies). Many 8742 general-purpose user agents (i.e., Web browsers) have taken steps to 8743 reduce their fingerprints. 8745 There are a number of request header fields that might reveal 8746 information to servers that is sufficiently unique to enable 8747 fingerprinting. The From header field is the most obvious, though it 8748 is expected that From will only be sent when self-identification is 8749 desired by the user. Likewise, Cookie header fields are deliberately 8750 designed to enable re-identification, so fingerprinting concerns only 8751 apply to situations where cookies are disabled or restricted by the 8752 user agent's configuration. 8754 The User-Agent header field might contain enough information to 8755 uniquely identify a specific device, usually when combined with other 8756 characteristics, particularly if the user agent sends excessive 8757 details about the user's system or extensions. However, the source 8758 of unique information that is least expected by users is proactive 8759 negotiation (Section 12.1), including the Accept, Accept-Charset, 8760 Accept-Encoding, and Accept-Language header fields. 8762 In addition to the fingerprinting concern, detailed use of the 8763 Accept-Language header field can reveal information the user might 8764 consider to be of a private nature. For example, understanding a 8765 given language set might be strongly correlated to membership in a 8766 particular ethnic group. An approach that limits such loss of 8767 privacy would be for a user agent to omit the sending of Accept- 8768 Language except for sites that have been explicitly permitted, 8769 perhaps via interaction after detecting a Vary header field that 8770 indicates language negotiation might be useful. 8772 In environments where proxies are used to enhance privacy, user 8773 agents ought to be conservative in sending proactive negotiation 8774 header fields. General-purpose user agents that provide a high 8775 degree of header field configurability ought to inform users about 8776 the loss of privacy that might result if too much detail is provided. 8777 As an extreme privacy measure, proxies could filter the proactive 8778 negotiation header fields in relayed requests. 8780 17.14. Validator Retention 8782 The validators defined by this specification are not intended to 8783 ensure the validity of a representation, guard against malicious 8784 changes, or detect on-path attacks. At best, they enable more 8785 efficient cache updates and optimistic concurrent writes when all 8786 participants are behaving nicely. At worst, the conditions will fail 8787 and the client will receive a response that is no more harmful than 8788 an HTTP exchange without conditional requests. 8790 An entity-tag can be abused in ways that create privacy risks. For 8791 example, a site might deliberately construct a semantically invalid 8792 entity-tag that is unique to the user or user agent, send it in a 8793 cacheable response with a long freshness time, and then read that 8794 entity-tag in later conditional requests as a means of re-identifying 8795 that user or user agent. Such an identifying tag would become a 8796 persistent identifier for as long as the user agent retained the 8797 original cache entry. User agents that cache representations ought 8798 to ensure that the cache is cleared or replaced whenever the user 8799 performs privacy-maintaining actions, such as clearing stored cookies 8800 or changing to a private browsing mode. 8802 17.15. Denial-of-Service Attacks Using Range 8804 Unconstrained multiple range requests are susceptible to denial-of- 8805 service attacks because the effort required to request many 8806 overlapping ranges of the same data is tiny compared to the time, 8807 memory, and bandwidth consumed by attempting to serve the requested 8808 data in many parts. Servers ought to ignore, coalesce, or reject 8809 egregious range requests, such as requests for more than two 8810 overlapping ranges or for many small ranges in a single set, 8811 particularly when the ranges are requested out of order for no 8812 apparent reason. Multipart range requests are not designed to 8813 support random access. 8815 17.16. Authentication Considerations 8817 Everything about the topic of HTTP authentication is a security 8818 consideration, so the list of considerations below is not exhaustive. 8819 Furthermore, it is limited to security considerations regarding the 8820 authentication framework, in general, rather than discussing all of 8821 the potential considerations for specific authentication schemes 8822 (which ought to be documented in the specifications that define those 8823 schemes). Various organizations maintain topical information and 8824 links to current research on Web application security (e.g., 8825 [OWASP]), including common pitfalls for implementing and using the 8826 authentication schemes found in practice. 8828 17.16.1. Confidentiality of Credentials 8830 The HTTP authentication framework does not define a single mechanism 8831 for maintaining the confidentiality of credentials; instead, each 8832 authentication scheme defines how the credentials are encoded prior 8833 to transmission. While this provides flexibility for the development 8834 of future authentication schemes, it is inadequate for the protection 8835 of existing schemes that provide no confidentiality on their own, or 8836 that do not sufficiently protect against replay attacks. 8837 Furthermore, if the server expects credentials that are specific to 8838 each individual user, the exchange of those credentials will have the 8839 effect of identifying that user even if the content within 8840 credentials remains confidential. 8842 HTTP depends on the security properties of the underlying transport- 8843 or session-level connection to provide confidential transmission of 8844 fields. Services that depend on individual user authentication 8845 require a secured connection prior to exchanging credentials 8846 (Section 4.2.2). 8848 17.16.2. Credentials and Idle Clients 8850 Existing HTTP clients and user agents typically retain authentication 8851 information indefinitely. HTTP does not provide a mechanism for the 8852 origin server to direct clients to discard these cached credentials, 8853 since the protocol has no awareness of how credentials are obtained 8854 or managed by the user agent. The mechanisms for expiring or 8855 revoking credentials can be specified as part of an authentication 8856 scheme definition. 8858 Circumstances under which credential caching can interfere with the 8859 application's security model include but are not limited to: 8861 * Clients that have been idle for an extended period, following 8862 which the server might wish to cause the client to re-prompt the 8863 user for credentials. 8865 * Applications that include a session termination indication (such 8866 as a "logout" or "commit" button on a page) after which the server 8867 side of the application "knows" that there is no further reason 8868 for the client to retain the credentials. 8870 User agents that cache credentials are encouraged to provide a 8871 readily accessible mechanism for discarding cached credentials under 8872 user control. 8874 17.16.3. Protection Spaces 8876 Authentication schemes that solely rely on the "realm" mechanism for 8877 establishing a protection space will expose credentials to all 8878 resources on an origin server. Clients that have successfully made 8879 authenticated requests with a resource can use the same 8880 authentication credentials for other resources on the same origin 8881 server. This makes it possible for a different resource to harvest 8882 authentication credentials for other resources. 8884 This is of particular concern when an origin server hosts resources 8885 for multiple parties under the same origin (Section 11.5). Possible 8886 mitigation strategies include restricting direct access to 8887 authentication credentials (i.e., not making the content of the 8888 Authorization request header field available), and separating 8889 protection spaces by using a different host name (or port number) for 8890 each party. 8892 17.16.4. Additional Response Fields 8894 Adding information to responses that are sent over an unencrypted 8895 channel can affect security and privacy. The presence of the 8896 Authentication-Info and Proxy-Authentication-Info header fields alone 8897 indicates that HTTP authentication is in use. Additional information 8898 could be exposed by the contents of the authentication-scheme 8899 specific parameters; this will have to be considered in the 8900 definitions of these schemes. 8902 18. IANA Considerations 8904 The change controller for the following registrations is: "IETF 8905 (iesg@ietf.org) - Internet Engineering Task Force". 8907 18.1. URI Scheme Registration 8909 Please update the registry of URI Schemes [BCP35] at 8910 with the permanent 8911 schemes listed in the table in Section 4.2. 8913 18.2. Method Registration 8915 Please update the "Hypertext Transfer Protocol (HTTP) Method 8916 Registry" at with the 8917 registration procedure of Section 16.1.1 and the method names 8918 summarized in the following table. 8920 +=========+======+============+=======+ 8921 | Method | Safe | Idempotent | Ref. | 8922 +=========+======+============+=======+ 8923 | CONNECT | no | no | 9.3.6 | 8924 +---------+------+------------+-------+ 8925 | DELETE | no | yes | 9.3.5 | 8926 +---------+------+------------+-------+ 8927 | GET | yes | yes | 9.3.1 | 8928 +---------+------+------------+-------+ 8929 | HEAD | yes | yes | 9.3.2 | 8930 +---------+------+------------+-------+ 8931 | OPTIONS | yes | yes | 9.3.7 | 8932 +---------+------+------------+-------+ 8933 | POST | no | no | 9.3.3 | 8934 +---------+------+------------+-------+ 8935 | PUT | no | yes | 9.3.4 | 8936 +---------+------+------------+-------+ 8937 | TRACE | yes | yes | 9.3.8 | 8938 +---------+------+------------+-------+ 8939 | * | no | no | 18.2 | 8940 +---------+------+------------+-------+ 8942 Table 7 8944 The method name "*" is reserved, since using "*" as a method name 8945 would conflict with its usage as a wildcard in some fields (e.g., 8946 "Access-Control-Request-Method"). 8948 18.3. Status Code Registration 8950 Please update the "Hypertext Transfer Protocol (HTTP) Status Code 8951 Registry" at 8952 with the registration procedure of Section 16.2.1 and the status code 8953 values summarized in the following table. 8955 +=======+===============================+=========+ 8956 | Value | Description | Ref. | 8957 +=======+===============================+=========+ 8958 | 100 | Continue | 15.2.1 | 8959 +-------+-------------------------------+---------+ 8960 | 101 | Switching Protocols | 15.2.2 | 8961 +-------+-------------------------------+---------+ 8962 | 200 | OK | 15.3.1 | 8963 +-------+-------------------------------+---------+ 8964 | 201 | Created | 15.3.2 | 8965 +-------+-------------------------------+---------+ 8966 | 202 | Accepted | 15.3.3 | 8967 +-------+-------------------------------+---------+ 8968 | 203 | Non-Authoritative Information | 15.3.4 | 8969 +-------+-------------------------------+---------+ 8970 | 204 | No Content | 15.3.5 | 8971 +-------+-------------------------------+---------+ 8972 | 205 | Reset Content | 15.3.6 | 8973 +-------+-------------------------------+---------+ 8974 | 206 | Partial Content | 15.3.7 | 8975 +-------+-------------------------------+---------+ 8976 | 300 | Multiple Choices | 15.4.1 | 8977 +-------+-------------------------------+---------+ 8978 | 301 | Moved Permanently | 15.4.2 | 8979 +-------+-------------------------------+---------+ 8980 | 302 | Found | 15.4.3 | 8981 +-------+-------------------------------+---------+ 8982 | 303 | See Other | 15.4.4 | 8983 +-------+-------------------------------+---------+ 8984 | 304 | Not Modified | 15.4.5 | 8985 +-------+-------------------------------+---------+ 8986 | 305 | Use Proxy | 15.4.6 | 8987 +-------+-------------------------------+---------+ 8988 | 306 | (Unused) | 15.4.7 | 8989 +-------+-------------------------------+---------+ 8990 | 307 | Temporary Redirect | 15.4.8 | 8991 +-------+-------------------------------+---------+ 8992 | 308 | Permanent Redirect | 15.4.9 | 8993 +-------+-------------------------------+---------+ 8994 | 400 | Bad Request | 15.5.1 | 8995 +-------+-------------------------------+---------+ 8996 | 401 | Unauthorized | 15.5.2 | 8997 +-------+-------------------------------+---------+ 8998 | 402 | Payment Required | 15.5.3 | 8999 +-------+-------------------------------+---------+ 9000 | 403 | Forbidden | 15.5.4 | 9001 +-------+-------------------------------+---------+ 9002 | 404 | Not Found | 15.5.5 | 9003 +-------+-------------------------------+---------+ 9004 | 405 | Method Not Allowed | 15.5.6 | 9005 +-------+-------------------------------+---------+ 9006 | 406 | Not Acceptable | 15.5.7 | 9007 +-------+-------------------------------+---------+ 9008 | 407 | Proxy Authentication Required | 15.5.8 | 9009 +-------+-------------------------------+---------+ 9010 | 408 | Request Timeout | 15.5.9 | 9011 +-------+-------------------------------+---------+ 9012 | 409 | Conflict | 15.5.10 | 9013 +-------+-------------------------------+---------+ 9014 | 410 | Gone | 15.5.11 | 9015 +-------+-------------------------------+---------+ 9016 | 411 | Length Required | 15.5.12 | 9017 +-------+-------------------------------+---------+ 9018 | 412 | Precondition Failed | 15.5.13 | 9019 +-------+-------------------------------+---------+ 9020 | 413 | Content Too Large | 15.5.14 | 9021 +-------+-------------------------------+---------+ 9022 | 414 | URI Too Long | 15.5.15 | 9023 +-------+-------------------------------+---------+ 9024 | 415 | Unsupported Media Type | 15.5.16 | 9025 +-------+-------------------------------+---------+ 9026 | 416 | Range Not Satisfiable | 15.5.17 | 9027 +-------+-------------------------------+---------+ 9028 | 417 | Expectation Failed | 15.5.18 | 9029 +-------+-------------------------------+---------+ 9030 | 418 | (Unused) | 15.5.19 | 9031 +-------+-------------------------------+---------+ 9032 | 421 | Misdirected Request | 15.5.20 | 9033 +-------+-------------------------------+---------+ 9034 | 422 | Unprocessable Content | 15.5.21 | 9035 +-------+-------------------------------+---------+ 9036 | 426 | Upgrade Required | 15.5.22 | 9037 +-------+-------------------------------+---------+ 9038 | 500 | Internal Server Error | 15.6.1 | 9039 +-------+-------------------------------+---------+ 9040 | 501 | Not Implemented | 15.6.2 | 9041 +-------+-------------------------------+---------+ 9042 | 502 | Bad Gateway | 15.6.3 | 9043 +-------+-------------------------------+---------+ 9044 | 503 | Service Unavailable | 15.6.4 | 9045 +-------+-------------------------------+---------+ 9046 | 504 | Gateway Timeout | 15.6.5 | 9047 +-------+-------------------------------+---------+ 9048 | 505 | HTTP Version Not Supported | 15.6.6 | 9049 +-------+-------------------------------+---------+ 9050 Table 8 9052 18.4. Field Name Registration 9054 This specification updates the HTTP related aspects of the existing 9055 registration procedures for message header fields defined in 9056 [RFC3864]. It defines both a new registration procedure and moves 9057 HTTP field definitions into a separate registry. 9059 Please create a new registry as outlined in Section 16.3.1. 9061 After creating the registry, all entries in the Permanent and 9062 Provisional Message Header Registries with the protocol 'http' are to 9063 be moved to it, with the following changes applied: 9065 1. The 'Applicable Protocol' field is to be omitted. 9067 2. Entries with a status of 'standard', 'experimental', 'reserved', 9068 or 'informational' are to have a status of 'permanent'. 9070 3. Provisional entries without a status are to have a status of 9071 'provisional'. 9073 4. Permanent entries without a status (after confirmation that the 9074 registration document did not define one) will have a status of 9075 'provisional'. The Expert(s) can choose to update their status 9076 if there is evidence that another is more appropriate. 9078 Please annotate the Permanent and Provisional Message Header 9079 registries to indicate that HTTP field name registrations have moved, 9080 with an appropriate link. 9082 After that is complete, please update the new registry with the field 9083 names listed in the following table. 9085 +===========================+============+========+============+ 9086 | Field Name | Status | Ref. | Comments | 9087 +===========================+============+========+============+ 9088 | Accept | standard | 12.5.1 | | 9089 +---------------------------+------------+--------+------------+ 9090 | Accept-Charset | deprecated | 12.5.2 | | 9091 +---------------------------+------------+--------+------------+ 9092 | Accept-Encoding | standard | 12.5.3 | | 9093 +---------------------------+------------+--------+------------+ 9094 | Accept-Language | standard | 12.5.4 | | 9095 +---------------------------+------------+--------+------------+ 9096 | Accept-Ranges | standard | 14.3 | | 9097 +---------------------------+------------+--------+------------+ 9098 | Allow | standard | 10.2.1 | | 9099 +---------------------------+------------+--------+------------+ 9100 | Authentication-Info | standard | 11.6.3 | | 9101 +---------------------------+------------+--------+------------+ 9102 | Authorization | standard | 11.6.2 | | 9103 +---------------------------+------------+--------+------------+ 9104 | Connection | standard | 7.6.1 | | 9105 +---------------------------+------------+--------+------------+ 9106 | Content-Encoding | standard | 8.4 | | 9107 +---------------------------+------------+--------+------------+ 9108 | Content-Language | standard | 8.5 | | 9109 +---------------------------+------------+--------+------------+ 9110 | Content-Length | standard | 8.6 | | 9111 +---------------------------+------------+--------+------------+ 9112 | Content-Location | standard | 8.7 | | 9113 +---------------------------+------------+--------+------------+ 9114 | Content-Range | standard | 14.4 | | 9115 +---------------------------+------------+--------+------------+ 9116 | Content-Type | standard | 8.3 | | 9117 +---------------------------+------------+--------+------------+ 9118 | Date | standard | 10.2.2 | | 9119 +---------------------------+------------+--------+------------+ 9120 | ETag | standard | 8.8.3 | | 9121 +---------------------------+------------+--------+------------+ 9122 | Expect | standard | 10.1.1 | | 9123 +---------------------------+------------+--------+------------+ 9124 | From | standard | 10.1.2 | | 9125 +---------------------------+------------+--------+------------+ 9126 | Host | standard | 7.2 | | 9127 +---------------------------+------------+--------+------------+ 9128 | If-Match | standard | 13.1.1 | | 9129 +---------------------------+------------+--------+------------+ 9130 | If-Modified-Since | standard | 13.1.3 | | 9131 +---------------------------+------------+--------+------------+ 9132 | If-None-Match | standard | 13.1.2 | | 9133 +---------------------------+------------+--------+------------+ 9134 | If-Range | standard | 13.1.5 | | 9135 +---------------------------+------------+--------+------------+ 9136 | If-Unmodified-Since | standard | 13.1.4 | | 9137 +---------------------------+------------+--------+------------+ 9138 | Last-Modified | standard | 8.8.2 | | 9139 +---------------------------+------------+--------+------------+ 9140 | Location | standard | 10.2.3 | | 9141 +---------------------------+------------+--------+------------+ 9142 | Max-Forwards | standard | 7.6.2 | | 9143 +---------------------------+------------+--------+------------+ 9144 | Proxy-Authenticate | standard | 11.7.1 | | 9145 +---------------------------+------------+--------+------------+ 9146 | Proxy-Authentication-Info | standard | 11.7.3 | | 9147 +---------------------------+------------+--------+------------+ 9148 | Proxy-Authorization | standard | 11.7.2 | | 9149 +---------------------------+------------+--------+------------+ 9150 | Range | standard | 14.2 | | 9151 +---------------------------+------------+--------+------------+ 9152 | Referer | standard | 10.1.3 | | 9153 +---------------------------+------------+--------+------------+ 9154 | Retry-After | standard | 10.2.4 | | 9155 +---------------------------+------------+--------+------------+ 9156 | Server | standard | 10.2.5 | | 9157 +---------------------------+------------+--------+------------+ 9158 | TE | standard | 10.1.4 | | 9159 +---------------------------+------------+--------+------------+ 9160 | Trailer | standard | 10.1.5 | | 9161 +---------------------------+------------+--------+------------+ 9162 | Upgrade | standard | 7.8 | | 9163 +---------------------------+------------+--------+------------+ 9164 | User-Agent | standard | 10.1.6 | | 9165 +---------------------------+------------+--------+------------+ 9166 | Vary | standard | 12.5.5 | | 9167 +---------------------------+------------+--------+------------+ 9168 | Via | standard | 7.6.3 | | 9169 +---------------------------+------------+--------+------------+ 9170 | WWW-Authenticate | standard | 11.6.1 | | 9171 +---------------------------+------------+--------+------------+ 9172 | * | standard | 12.5.5 | (reserved) | 9173 +---------------------------+------------+--------+------------+ 9175 Table 9 9177 The field name "*" is reserved, since using that name as an HTTP 9178 header field might conflict with its special semantics in the Vary 9179 header field (Section 12.5.5). 9181 Finally, please update the "Content-MD5" entry in the new registry to 9182 have a status of 'obsoleted' with references to Section 14.15 of 9183 [RFC2616] (for the definition of the header field) and Appendix B of 9184 [RFC7231] (which removed the field definition from the updated 9185 specification). 9187 18.5. Authentication Scheme Registration 9189 Please update the "Hypertext Transfer Protocol (HTTP) Authentication 9190 Scheme Registry" at with the registration procedure of Section 16.4.1. No 9192 authentication schemes are defined in this document. 9194 18.6. Content Coding Registration 9196 Please update the "HTTP Content Coding Registry" at 9197 with the 9198 registration procedure of Section 16.6.1 and the content coding names 9199 summarized in the table below. 9201 +============+===========================================+=========+ 9202 | Name | Description | Ref. | 9203 +============+===========================================+=========+ 9204 | compress | UNIX "compress" data format [Welch] | 8.4.1.1 | 9205 +------------+-------------------------------------------+---------+ 9206 | deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 | 9207 | | inside the "zlib" data format ([RFC1950]) | | 9208 +------------+-------------------------------------------+---------+ 9209 | gzip | GZIP file format [RFC1952] | 8.4.1.3 | 9210 +------------+-------------------------------------------+---------+ 9211 | identity | Reserved | 12.5.3 | 9212 +------------+-------------------------------------------+---------+ 9213 | x-compress | Deprecated (alias for compress) | 8.4.1.1 | 9214 +------------+-------------------------------------------+---------+ 9215 | x-gzip | Deprecated (alias for gzip) | 8.4.1.3 | 9216 +------------+-------------------------------------------+---------+ 9218 Table 10 9220 18.7. Range Unit Registration 9222 Please update the "HTTP Range Unit Registry" at 9223 with the 9224 registration procedure of Section 16.5.1 and the range unit names 9225 summarized in the table below. 9227 +=================+==================================+========+ 9228 | Range Unit Name | Description | Ref. | 9229 +=================+==================================+========+ 9230 | bytes | a range of octets | 14.1.2 | 9231 +-----------------+----------------------------------+--------+ 9232 | none | reserved as keyword to indicate | 14.3 | 9233 | | range requests are not supported | | 9234 +-----------------+----------------------------------+--------+ 9236 Table 11 9238 18.8. Media Type Registration 9240 Please update the "Media Types" registry at 9241 with the registration 9242 information in Section 14.6 for the media type "multipart/ 9243 byteranges". 9245 18.9. Port Registration 9247 Please update the "Service Name and Transport Protocol Port Number" 9248 registry at for the services on ports 80 and 443 that use UDP or TCP 9250 to: 9252 1. use this document as "Reference", and 9254 2. when currently unspecified, set "Assignee" to "IESG" and 9255 "Contact" to "IETF_Chair". 9257 18.10. Upgrade Token Registration 9259 Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token 9260 Registry" at 9261 with the registration procedure of Section 16.7 and the upgrade token 9262 names summarized in the following table. 9264 +======+===================+=========================+======+ 9265 | Name | Description | Expected Version Tokens | Ref. | 9266 +======+===================+=========================+======+ 9267 | HTTP | Hypertext | any DIGIT.DIGIT (e.g, | 2.5 | 9268 | | Transfer Protocol | "2.0") | | 9269 +------+-------------------+-------------------------+------+ 9271 Table 12 9273 19. References 9275 19.1. Normative References 9277 [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 9278 Ed., "HTTP Caching", Work in Progress, Internet-Draft, 9279 draft-ietf-httpbis-cache-17, 26 July 2021, 9280 . 9283 [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data 9284 Format Specification version 3.3", RFC 1950, 9285 DOI 10.17487/RFC1950, May 1996, 9286 . 9288 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 9289 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 9290 . 9292 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and 9293 G. Randers-Pehrson, "GZIP file format specification 9294 version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, 9295 . 9297 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 9298 Extensions (MIME) Part Two: Media Types", RFC 2046, 9299 DOI 10.17487/RFC2046, November 1996, 9300 . 9302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9303 Requirement Levels", BCP 14, RFC 2119, 9304 DOI 10.17487/RFC2119, March 1997, 9305 . 9307 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 9308 Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 9309 2006, . 9311 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 9312 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 9313 . 9315 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 9316 Specifications: ABNF", STD 68, RFC 5234, 9317 DOI 10.17487/RFC5234, January 2008, 9318 . 9320 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 9321 Housley, R., and W. Polk, "Internet X.509 Public Key 9322 Infrastructure Certificate and Certificate Revocation List 9323 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 9324 . 9326 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 9327 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 9328 September 2009, . 9330 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 9331 Verification of Domain-Based Application Service Identity 9332 within Internet Public Key Infrastructure Using X.509 9333 (PKIX) Certificates in the Context of Transport Layer 9334 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 9335 2011, . 9337 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 9338 Internationalization in the IETF", BCP 166, RFC 6365, 9339 DOI 10.17487/RFC6365, September 2011, 9340 . 9342 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 9343 RFC 7405, DOI 10.17487/RFC7405, December 2014, 9344 . 9346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 9347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 9348 May 2017, . 9350 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 9351 RFC 793, DOI 10.17487/RFC0793, September 1981, 9352 . 9354 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 9355 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 9356 . 9358 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 9359 Resource Identifier (URI): Generic Syntax", STD 66, 9360 RFC 3986, DOI 10.17487/RFC3986, January 2005, 9361 . 9363 [USASCII] American National Standards Institute, "Coded Character 9364 Set -- 7-bit American Standard Code for Information 9365 Interchange", ANSI X3.4, 1986. 9367 [Welch] Welch, T. A., "A Technique for High-Performance Data 9368 Compression", IEEE Computer 17(6), 9369 DOI 10.1109/MC.1984.1659158, June 1984, 9370 . 9372 19.2. Informative References 9374 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 9375 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 9376 April 2016, . 9378 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 9379 Specifications and Registration Procedures", BCP 13, 9380 RFC 6838, January 2013, 9381 . 9383 [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, 9384 "Deprecating the "X-" Prefix and Similar Constructs in 9385 Application Protocols", BCP 178, RFC 6648, June 2012, 9386 . 9388 [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 9389 and Registration Procedures for URI Schemes", BCP 35, 9390 RFC 7595, June 2015, 9391 . 9393 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the 9394 CRIME Attack", July 2013, 9395 . 9398 [Bujlow] Bujlow, T., Carela-Espanol, V., Sole-Pareta, J., and P. 9399 Barlet-Ros, "A Survey on Web Tracking: Mechanisms, 9400 Implications, and Defenses", 9401 DOI 10.1109/JPROC.2016.2637878, Proceedings of the 9402 IEEE 105(8), August 2017, 9403 . 9405 [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, 9406 DOI 10.17487/RFC6265, April 2011, 9407 . 9409 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978, 9410 . 9412 [Err5433] RFC Errata, Erratum ID 5433, RFC 2978, 9413 . 9415 [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, 9416 D., and V. Shmatikov, "The Most Dangerous Code in the 9417 World: Validating SSL Certificates in Non-browser 9418 Software", In Proceedings of the 2012 ACM Conference on 9419 Computer and Communications Security (CCS '12), pp. 38-49, 9420 DOI 10.1145/2382196.2382204, October 2012, 9421 . 9423 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 9424 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 9425 . 9427 [HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen, 9428 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 9429 DOI 10.17487/RFC1945, May 1996, 9430 . 9432 [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 9433 Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- 9434 ietf-httpbis-messaging-17, 26 July 2021, 9435 . 9438 [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 9439 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 9440 DOI 10.17487/RFC7540, May 2015, 9441 . 9443 [HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3 9444 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 9445 quic-http-34, 2 February 2021, 9446 . 9449 [ISO-8859-1] 9450 International Organization for Standardization, 9451 "Information technology -- 8-bit single-byte coded graphic 9452 character sets -- Part 1: Latin alphabet No. 1", ISO/ 9453 IEC 8859-1:1998, 1998. 9455 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 9456 Politics", ACM Transactions on Internet Technology 1(2), 9457 November 2001, . 9459 [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web 9460 Applications and Web Services", The Open Web Application 9461 Security Project (OWASP) 2.0.1, 27 July 2005, 9462 . 9464 [REST] Fielding, R.T., "Architectural Styles and the Design of 9465 Network-based Software Architectures", Doctoral 9466 Dissertation, University of California, Irvine, September 9467 2000, . 9469 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 9470 RFC 1919, DOI 10.17487/RFC1919, March 1996, 9471 . 9473 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 9474 Part Three: Message Header Extensions for Non-ASCII Text", 9475 RFC 2047, DOI 10.17487/RFC2047, November 1996, 9476 . 9478 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 9479 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 9480 RFC 2068, DOI 10.17487/RFC2068, January 1997, 9481 . 9483 [RFC2145] Mogul, J.C., Fielding, R.T., Gettys, J., and H.F. Nielsen, 9484 "Use and Interpretation of HTTP Version Numbers", 9485 RFC 2145, DOI 10.17487/RFC2145, May 1997, 9486 . 9488 [RFC2295] Holtman, K. and A.H. Mutz, "Transparent Content 9489 Negotiation in HTTP", RFC 2295, DOI 10.17487/RFC2295, 9490 March 1998, . 9492 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol 9493 (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, 1 April 9494 1998, . 9496 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 9497 "MIME Encapsulation of Aggregate Documents, such as HTML 9498 (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, 9499 . 9501 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 9502 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 9503 Transfer Protocol -- HTTP/1.1", RFC 2616, 9504 DOI 10.17487/RFC2616, June 1999, 9505 . 9507 [RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, 9508 S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP 9509 Authentication: Basic and Digest Access Authentication", 9510 RFC 2617, DOI 10.17487/RFC2617, June 1999, 9511 . 9513 [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP 9514 Extension Framework", RFC 2774, DOI 10.17487/RFC2774, 9515 February 2000, . 9517 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 9518 DOI 10.17487/RFC2818, May 2000, 9519 . 9521 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 9522 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 9523 October 2000, . 9525 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 9526 Replication and Caching Taxonomy", RFC 3040, 9527 DOI 10.17487/RFC3040, January 2001, 9528 . 9530 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 9531 Procedures for Message Header Fields", BCP 90, RFC 3864, 9532 DOI 10.17487/RFC3864, September 2004, 9533 . 9535 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 9536 (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875, 9537 October 2004, . 9539 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 9540 Rose, "DNS Security Introduction and Requirements", 9541 RFC 4033, DOI 10.17487/RFC4033, March 2005, 9542 . 9544 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 9545 Kerberos and NTLM HTTP Authentication in Microsoft 9546 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 9547 . 9549 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 9550 DOI 10.17487/RFC5322, October 2008, 9551 . 9553 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 9554 RFC 5789, DOI 10.17487/RFC5789, March 2010, 9555 . 9557 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 9558 "Network Time Protocol Version 4: Protocol and Algorithms 9559 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 9560 . 9562 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 9563 DOI 10.17487/RFC6454, December 2011, 9564 . 9566 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 9567 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 9568 . 9570 [RFC7230] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 9571 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 9572 RFC 7230, DOI 10.17487/RFC7230, June 2014, 9573 . 9575 [RFC7231] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 9576 Transfer Protocol (HTTP/1.1): Semantics and Content", 9577 RFC 7231, DOI 10.17487/RFC7231, June 2014, 9578 . 9580 [RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 9581 Transfer Protocol (HTTP/1.1): Conditional Requests", 9582 RFC 7232, DOI 10.17487/RFC7232, June 2014, 9583 . 9585 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed., 9586 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 9587 RFC 7233, DOI 10.17487/RFC7233, June 2014, 9588 . 9590 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, 9591 Ed., "Hypertext Transfer Protocol (HTTP): Caching", 9592 RFC 7234, DOI 10.17487/RFC7234, June 2014, 9593 . 9595 [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 9596 Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, 9597 DOI 10.17487/RFC7235, June 2014, 9598 . 9600 [RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status 9601 Code 308 (Permanent Redirect)", RFC 7538, 9602 DOI 10.17487/RFC7538, April 2015, 9603 . 9605 [RFC7578] Masinter, L., "Returning Values from Forms: multipart/ 9606 form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, 9607 . 9609 [RFC7615] Reschke, J. F., "HTTP Authentication-Info and Proxy- 9610 Authentication-Info Response Header Fields", RFC 7615, 9611 DOI 10.17487/RFC7615, September 2015, 9612 . 9614 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 9615 Digest Access Authentication", RFC 7616, 9616 DOI 10.17487/RFC7616, September 2015, 9617 . 9619 [RFC7617] Reschke, J. F., "The 'Basic' HTTP Authentication Scheme", 9620 RFC 7617, DOI 10.17487/RFC7617, September 2015, 9621 . 9623 [RFC7694] Reschke, J. F., "Hypertext Transfer Protocol (HTTP) 9624 Client-Initiated Content-Encoding", RFC 7694, 9625 DOI 10.17487/RFC7694, November 2015, 9626 . 9628 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 9629 Writing an IANA Considerations Section in RFCs", BCP 26, 9630 RFC 8126, DOI 10.17487/RFC8126, June 2017, 9631 . 9633 [RFC8187] Reschke, J. F., "Indicating Character Encoding and 9634 Language for HTTP Header Field Parameters", RFC 8187, 9635 DOI 10.17487/RFC8187, September 2017, 9636 . 9638 [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, 9639 DOI 10.17487/RFC8246, September 2017, 9640 . 9642 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 9643 DOI 10.17487/RFC8288, October 2017, 9644 . 9646 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 9647 RFC 8336, DOI 10.17487/RFC8336, March 2018, 9648 . 9650 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 9651 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 9652 . 9654 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 9655 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 9656 . 9658 [Sniffing] WHATWG, "MIME Sniffing", 9659 . 9661 [WEBDAV] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed 9662 Authoring and Versioning (WebDAV)", RFC 4918, 9663 DOI 10.17487/RFC4918, June 2007, 9664 . 9666 Appendix A. Collected ABNF 9668 In the collected ABNF below, list rules are expanded as per 9669 Section 5.6.1.1. 9671 Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [ 9672 weight ] ) ) ] 9673 Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( ( 9674 token / "*" ) [ weight ] ) ) ] 9675 Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ 9676 weight ] ) ) ] 9677 Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS ( 9678 language-range [ weight ] ) ) ] 9679 Accept-Ranges = acceptable-ranges 9680 Allow = [ method *( OWS "," OWS method ) ] 9681 Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ] 9682 Authorization = credentials 9684 BWS = OWS 9686 Connection = [ connection-option *( OWS "," OWS connection-option ) 9687 ] 9688 Content-Encoding = [ content-coding *( OWS "," OWS content-coding ) 9689 ] 9690 Content-Language = [ language-tag *( OWS "," OWS language-tag ) ] 9691 Content-Length = 1*DIGIT 9692 Content-Location = absolute-URI / partial-URI 9693 Content-Range = range-unit SP ( range-resp / unsatisfied-range ) 9694 Content-Type = media-type 9696 Date = HTTP-date 9698 ETag = entity-tag 9699 Expect = [ expectation *( OWS "," OWS expectation ) ] 9701 From = mailbox 9703 GMT = %x47.4D.54 ; GMT 9705 HTTP-date = IMF-fixdate / obs-date 9706 Host = uri-host [ ":" port ] 9708 IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT 9709 If-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ] 9710 If-Modified-Since = HTTP-date 9711 If-None-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ] 9712 If-Range = entity-tag / HTTP-date 9713 If-Unmodified-Since = HTTP-date 9714 Last-Modified = HTTP-date 9715 Location = URI-reference 9717 Max-Forwards = 1*DIGIT 9719 OWS = *( SP / HTAB ) 9721 Proxy-Authenticate = [ challenge *( OWS "," OWS challenge ) ] 9722 Proxy-Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) 9723 ] 9724 Proxy-Authorization = credentials 9726 RWS = 1*( SP / HTAB ) 9727 Range = ranges-specifier 9728 Referer = absolute-URI / partial-URI 9729 Retry-After = HTTP-date / delay-seconds 9731 Server = product *( RWS ( product / comment ) ) 9733 TE = [ t-codings *( OWS "," OWS t-codings ) ] 9734 Trailer = [ field-name *( OWS "," OWS field-name ) ] 9736 URI-reference = 9737 Upgrade = [ protocol *( OWS "," OWS protocol ) ] 9738 User-Agent = product *( RWS ( product / comment ) ) 9740 Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) ) 9741 ] 9742 Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS 9743 "," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ] 9745 WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ] 9747 absolute-URI = 9748 absolute-path = 1*( "/" segment ) 9749 acceptable-ranges = range-unit *( OWS "," OWS range-unit ) 9750 asctime-date = day-name SP date3 SP time-of-day SP year 9751 auth-param = token BWS "=" BWS ( token / quoted-string ) 9752 auth-scheme = token 9753 authority = 9755 challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," 9756 OWS auth-param ) ] ) ] 9757 codings = content-coding / "identity" / "*" 9758 comment = "(" *( ctext / quoted-pair / comment ) ")" 9759 complete-length = 1*DIGIT 9760 connection-option = token 9761 content-coding = token 9762 credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," 9763 OWS auth-param ) ] ) ] 9764 ctext = HTAB / SP / %x21-27 ; '!'-''' 9765 / %x2A-5B ; '*'-'[' 9766 / %x5D-7E ; ']'-'~' 9767 / obs-text 9769 date1 = day SP month SP year 9770 date2 = day "-" month "-" 2DIGIT 9771 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 9772 day = 2DIGIT 9773 day-name = %x4D.6F.6E ; Mon 9774 / %x54.75.65 ; Tue 9775 / %x57.65.64 ; Wed 9776 / %x54.68.75 ; Thu 9777 / %x46.72.69 ; Fri 9778 / %x53.61.74 ; Sat 9779 / %x53.75.6E ; Sun 9780 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 9781 / %x54.75.65.73.64.61.79 ; Tuesday 9782 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 9783 / %x54.68.75.72.73.64.61.79 ; Thursday 9784 / %x46.72.69.64.61.79 ; Friday 9785 / %x53.61.74.75.72.64.61.79 ; Saturday 9786 / %x53.75.6E.64.61.79 ; Sunday 9787 delay-seconds = 1*DIGIT 9789 entity-tag = [ weak ] opaque-tag 9790 etagc = "!" / %x23-7E ; '#'-'~' 9791 / obs-text 9792 expectation = token [ "=" ( token / quoted-string ) parameters ] 9794 field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) 9795 field-vchar ] 9796 field-name = token 9797 field-value = *field-content 9798 field-vchar = VCHAR / obs-text 9799 first-pos = 1*DIGIT 9801 hour = 2DIGIT 9802 http-URI = "http://" authority path-abempty [ "?" query ] 9803 https-URI = "https://" authority path-abempty [ "?" query ] 9805 incl-range = first-pos "-" last-pos 9806 int-range = first-pos "-" [ last-pos ] 9808 language-range = 9809 language-tag = 9810 last-pos = 1*DIGIT 9812 mailbox = 9813 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) 9814 parameters 9815 media-type = type "/" subtype parameters 9816 method = token 9817 minute = 2DIGIT 9818 month = %x4A.61.6E ; Jan 9819 / %x46.65.62 ; Feb 9820 / %x4D.61.72 ; Mar 9821 / %x41.70.72 ; Apr 9822 / %x4D.61.79 ; May 9823 / %x4A.75.6E ; Jun 9824 / %x4A.75.6C ; Jul 9825 / %x41.75.67 ; Aug 9826 / %x53.65.70 ; Sep 9827 / %x4F.63.74 ; Oct 9828 / %x4E.6F.76 ; Nov 9829 / %x44.65.63 ; Dec 9831 obs-date = rfc850-date / asctime-date 9832 obs-text = %x80-FF 9833 opaque-tag = DQUOTE *etagc DQUOTE 9834 other-range = 1*( %x21-2B ; '!'-'+' 9835 / %x2D-7E ; '-'-'~' 9836 ) 9838 parameter = parameter-name "=" parameter-value 9839 parameter-name = token 9840 parameter-value = ( token / quoted-string ) 9841 parameters = *( OWS ";" OWS [ parameter ] ) 9842 partial-URI = relative-part [ "?" query ] 9843 path-abempty = 9844 port = 9845 product = token [ "/" product-version ] 9846 product-version = token 9847 protocol = protocol-name [ "/" protocol-version ] 9848 protocol-name = token 9849 protocol-version = token 9850 pseudonym = token 9852 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' 9853 / %x5D-7E ; ']'-'~' 9854 / obs-text 9855 query = 9856 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 9857 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 9858 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 9860 range-resp = incl-range "/" ( complete-length / "*" ) 9861 range-set = range-spec *( OWS "," OWS range-spec ) 9862 range-spec = int-range / suffix-range / other-range 9863 range-unit = token 9864 ranges-specifier = range-unit "=" range-set 9865 received-by = pseudonym [ ":" port ] 9866 received-protocol = [ protocol-name "/" ] protocol-version 9867 relative-part = 9868 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 9870 second = 2DIGIT 9871 segment = 9872 subtype = token 9873 suffix-length = 1*DIGIT 9874 suffix-range = "-" suffix-length 9876 t-codings = "trailers" / ( transfer-coding [ weight ] ) 9877 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 9878 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 9879 time-of-day = hour ":" minute ":" second 9880 token = 1*tchar 9881 token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) 9882 *"=" 9883 transfer-coding = token *( OWS ";" OWS transfer-parameter ) 9884 transfer-parameter = token BWS "=" BWS ( token / quoted-string ) 9885 type = token 9887 unsatisfied-range = "*/" complete-length 9888 uri-host = 9890 weak = %x57.2F ; W/ 9891 weight = OWS ";" OWS "q=" qvalue 9893 year = 4DIGIT 9895 Appendix B. Changes from previous RFCs 9897 B.1. Changes from RFC 2818 9899 None. 9901 B.2. Changes from RFC 7230 9903 The sections introducing HTTP's design goals, history, architecture, 9904 conformance criteria, protocol versioning, URIs, message routing, and 9905 header fields have been moved here. 9907 The requirement on semantic conformance has been replaced with 9908 permission to ignore/workaround implementation-specific failures. 9909 (Section 2.2) 9911 The description of an origin and authoritative access to origin 9912 servers has been extended for both "http" and "https" URIs to account 9913 for alternative services and secured connections that are not 9914 necessarily based on TCP. (Section 4.2.1, Section 4.2.2, 9915 Section 4.3.1, Section 7.3.3) 9917 Explicit requirements have been added to check the target URI 9918 scheme's semantics and reject requests that don't meet any associated 9919 requirements. (Section 7.4) 9921 Parameters in media type, media range, and expectation can be empty 9922 via one or more trailing semicolons. (Section 5.6.6) 9924 "Field value" now refers to the value after multiple field lines are 9925 combined with commas - by far the most common use. To refer to a 9926 single header line's value, use "field line value". (Section 6.3) 9928 Trailer field semantics now transcend the specifics of chunked 9929 encoding. Use of trailer fields has been further limited to only 9930 allow generation as a trailer field when the sender knows the field 9931 defines that usage and to only allow merging into the header section 9932 if the recipient knows the corresponding field definition permits and 9933 defines how to merge. In all other cases, implementations are 9934 encouraged to either store the trailer fields separately or discard 9935 them instead of merging. (Section 6.5.1) 9937 Made the priority of the absolute form of the request URI over the 9938 Host header by origin servers explicit, to align with proxy handling. 9939 (Section 7.2) 9941 The grammar definition for the Via field's "received-by" was expanded 9942 in 7230 due to changes in the URI grammar for host [URI] that are not 9943 desirable for Via. For simplicity, we have removed uri-host from the 9944 received-by production because it can be encompassed by the existing 9945 grammar for pseudonym. In particular, this change removed comma from 9946 the allowed set of charaters for a host name in received-by. 9947 (Section 7.6.3) 9949 B.3. Changes from RFC 7231 9951 Minimum URI lengths to be supported by implementations are now 9952 recommended. (Section 3.1) 9953 Clarified that CR and NUL in field values are to be rejected or 9954 mapped to SP and that leading and trailing whitespace need to be 9955 stripped from field values before they are consumed. (Section 5.5) 9957 Parameters in media type, media range, and expectation can be empty 9958 via one or more trailing semicolons. (Section 5.6.6) 9960 An abstract data type for HTTP messages has been introduced to define 9961 the components of a message and their semantics as an abstraction 9962 across multiple HTTP versions, rather than in terms of the specific 9963 syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after 9964 the message is parsed. This makes it easier to distinguish between 9965 requirements on the content (what is conveyed) versus requirements on 9966 the messaging syntax (how it is conveyed) and avoids baking 9967 limitations of early protocol versions into the future of HTTP. 9968 (Section 6) 9970 The terms "payload" and "payload body" have been replaced with 9971 "content", to better align with its usage elsewhere (e.g., in field 9972 names) and to avoid confusion with frame payloads in HTTP/2 and 9973 HTTP/3. (Section 6.4) 9975 The term "effective request URI" has been replaced with "target URI". 9976 (Section 7.1) 9978 Restrictions on client retries have been loosened, to reflect 9979 implementation behavior. (Section 9.2.2) 9981 Clarified that request bodies on GET, HEAD, and DELETE are not 9982 interoperable. (Section 9.3.1, Section 9.3.2, Section 9.3.5) 9984 Allowed use of the Content-Range header field (Section 14.4) as a 9985 request modifier on PUT. (Section 9.3.4) 9987 Removed a superfluous requirement about setting Content-Length from 9988 the description of the OPTIONS method. (Section 9.3.7) 9990 Removed normative requirement to use the "message/http" media type in 9991 TRACE responses. (Section 9.3.8) 9993 Restore list-based grammar for Expect for compatibility with RFC 9994 2616. (Section 10.1.1) 9996 Allow Accept and Accept-Encoding in response messages; the latter was 9997 introduced by [RFC7694]. (Section 12.3) 9998 "Accept Parameters" (accept-params and accept-ext ABNF production) 9999 have been removed from the definition of the Accept field. 10000 (Section 12.5.1) 10002 The "Accept-Charset" field now is deprecated. (Section 12.5.2) 10004 The semantics of "*" in the Vary header field when other values are 10005 present was clarified. (Section 12.5.5) 10007 Range units are compared in a case insensitive fashion. 10008 (Section 14.1) 10010 Use of "Accept-Ranges" is not restricted to origin servers. 10011 (Section 14.3) 10013 The process of creating a redirected request has been clarified. 10014 (Section 15.4) 10016 Added status code 308 (previously defined in [RFC7538]) so that it's 10017 defined closer to status codes 301, 302, and 307. (Section 15.4.9) 10019 Added status code 421 (previously defined in Section 9.1.2 of 10020 [HTTP/2]) because of its general applicability. 421 is no longer 10021 defined as heuristically cacheable, since the response is specific to 10022 the connection (not the target resource). (Section 15.5.20) 10024 Added status code 422 (previously defined in Section 11.2 of 10025 [WEBDAV]) because of its general applicability. (Section 15.5.21) 10027 B.4. Changes from RFC 7232 10029 Previous revisions of HTTP imposed an arbitrary 60-second limit on 10030 the determination of whether Last-Modified was a strong validator to 10031 guard against the possibility that the Date and Last-Modified values 10032 are generated from different clocks or at somewhat different times 10033 during the preparation of the response. This specification has 10034 relaxed that to allow reasonable discretion. (Section 8.8.2.2) 10036 Removed edge case requirement on If-Match and If-Unmodified-Since 10037 that a validator not be sent in a 2xx response when validation fails 10038 and the server decides that the same change request has already been 10039 applied. (Section 13.1.1 and Section 13.1.4) 10041 Clarified that If-Unmodified-Since doesn't apply to a resource 10042 without a concept of modification time. (Section 13.1.4) 10043 Preconditions can now be evaluated before the request content is 10044 processed rather than waiting until the response would otherwise be 10045 successful. (Section 13.2) 10047 B.5. Changes from RFC 7233 10049 Refactored the range-unit and ranges-specifier grammars to simplify 10050 and reduce artificial distinctions between bytes and other 10051 (extension) range units, removing the overlapping grammar of other- 10052 range-unit by defining range units generically as a token and placing 10053 extensions within the scope of a range-spec (other-range). This 10054 disambiguates the role of list syntax (commas) in all range sets, 10055 including extension range units, for indicating a range-set of more 10056 than one range. Moving the extension grammar into range specifiers 10057 also allows protocol specific to byte ranges to be specified 10058 separately. 10060 It is now possible to define Range handling on extension methods. 10061 (Section 14.2) 10063 Described use of the Content-Range header field (Section 14.4) as a 10064 request modifier to perform a partial PUT. (Section 14.5) 10066 B.6. Changes from RFC 7235 10068 None. 10070 B.7. Changes from RFC 7538 10072 None. 10074 B.8. Changes from RFC 7615 10076 None. 10078 B.9. Changes from RFC 7694 10080 This specification includes the extension defined in [RFC7694], but 10081 leaves out examples and deployment considerations. 10083 Appendix C. Change Log 10085 This section is to be removed before publishing as an RFC. 10087 C.1. Between RFC723x and draft 00 10089 The changes were purely editorial: 10091 * Change boilerplate and abstract to indicate the "draft" status, 10092 and update references to ancestor specifications. 10094 * Remove version "1.1" from document title, indicating that this 10095 specification applies to all HTTP versions. 10097 * Adjust historical notes. 10099 * Update links to sibling specifications. 10101 * Replace sections listing changes from RFC 2616 by new empty 10102 sections referring to RFC 723x. 10104 * Remove acknowledgements specific to RFC 723x. 10106 * Move "Acknowledgements" to the very end and make them unnumbered. 10108 C.2. Since draft-ietf-httpbis-semantics-00 10110 The changes in this draft are editorial, with respect to HTTP as a 10111 whole, to merge core HTTP semantics into this document: 10113 * Merged introduction, architecture, conformance, and ABNF 10114 extensions from RFC 7230 (Messaging). 10116 * Rearranged architecture to extract conformance, http(s) schemes, 10117 and protocol versioning into a separate major section. 10119 * Moved discussion of MIME differences to [HTTP/1.1] since that is 10120 primarily concerned with transforming 1.1 messages. 10122 * Merged entire content of RFC 7232 (Conditional Requests). 10124 * Merged entire content of RFC 7233 (Range Requests). 10126 * Merged entire content of RFC 7235 (Auth Framework). 10128 * Moved all extensibility tips, registration procedures, and 10129 registry tables from the IANA considerations to normative 10130 sections, reducing the IANA considerations to just instructions 10131 that will be removed prior to publication as an RFC. 10133 C.3. Since draft-ietf-httpbis-semantics-01 10135 * Improve [Welch] citation () 10138 * Remove HTTP/1.1-ism about Range Requests 10139 () 10141 * Cite RFC 8126 instead of RFC 5226 () 10144 * Cite RFC 7538 instead of RFC 7238 () 10147 * Cite RFC 8288 instead of RFC 5988 () 10150 * Cite RFC 8187 instead of RFC 5987 () 10153 * Cite RFC 7578 instead of RFC 2388 () 10156 * Cite RFC 7595 instead of RFC 4395 () 10159 * improve ABNF readability for qdtext (, ) 10162 * Clarify "resource" vs "representation" in definition of status 10163 code 416 (, 10164 ) 10166 * Resolved erratum 4072, no change needed here 10167 (, 10168 ) 10170 * Clarify DELETE status code suggestions 10171 (, 10172 ) 10174 * In Section 14.4, fix ABNF for "other-range-resp" to use VCHAR 10175 instead of CHAR (, 10176 ) 10178 * Resolved erratum 5162, no change needed here 10179 (, 10180 ) 10182 * Replace "response code" with "response status code" and "status- 10183 code" (the ABNF production name from the HTTP/1.1 message format) 10184 by "status code" (, 10185 ) 10187 * Added a missing word in Section 15.4 (, ) 10190 * In Section 5.6.1, fixed an example that had trailing whitespace 10191 where it shouldn't (, ) 10194 * In Section 15.3.7, remove words that were potentially misleading 10195 with respect to the relation to the requested ranges 10196 (, 10197 ) 10199 C.4. Since draft-ietf-httpbis-semantics-02 10201 * Included (Proxy-)Auth-Info header field definition from RFC 7615 10202 () 10204 * In Section 9.3.3, clarify POST caching 10205 () 10207 * Add Section 15.5.19 to reserve the 418 status code 10208 () 10210 * In Section 3.4 and Section 10.1.1, clarified when a response can 10211 be sent () 10213 * In Section 8.3.2, explain the difference between the "token" 10214 production, the RFC 2978 ABNF for charset names, and the actual 10215 registration practice (, ) 10218 * In Section 3.1, removed the fragment component in the URI scheme 10219 definitions as per Section 4.3 of [URI], furthermore moved 10220 fragment discussion into a separate section 10221 (, 10222 , ) 10225 * In Section 2.5, add language about minor HTTP version number 10226 defaulting () 10228 * Added Section 15.5.21 for status code 422, previously defined in 10229 Section 11.2 of [WEBDAV] () 10232 * In Section 15.5.17, fixed prose about byte range comparison 10233 (, 10234 ) 10236 * In Section 3.4, explain that request/response correlation is 10237 version specific () 10240 C.5. Since draft-ietf-httpbis-semantics-03 10242 * In Section 15.4.9, include status code 308 from RFC 7538 10243 () 10245 * In Section 8.3.1, clarify that the charset parameter value is 10246 case-insensitive due to the definition in RFC 2046 10247 () 10249 * Define a separate registry for HTTP header field names 10250 () 10252 * In Section 12.1, refactor and clarify description of wildcard 10253 ("*") handling () 10255 * Deprecate Accept-Charset () 10258 * In Section 13.2, mention Cache-Control: immutable 10259 () 10261 * In Section 5.3, clarify when header field combination is allowed 10262 () 10264 * In Section 18.4, instruct IANA to mark Content-MD5 as obsolete 10265 () 10267 * Use RFC 7405 ABNF notation for case-sensitive string constants 10268 () 10270 * Rework Section 3.4 to be more version-independent 10271 () 10273 * In Section 9.3.5, clarify that DELETE needs to be successful to 10274 invalidate cache (, ) 10277 C.6. Since draft-ietf-httpbis-semantics-04 10279 * In Section 5.5, fix field-content ABNF 10280 (, 10281 ) 10283 * Move Section 5.6.6 into its own section 10284 () 10286 * In Section 8.3, reference MIME Sniffing 10287 () 10289 * In Section 5.6.1, simplify the #rule mapping for recipients 10290 (, 10291 ) 10293 * In Section 9.3.7, remove misleading text about "extension" of HTTP 10294 is needed to define method content () 10297 * Fix editorial issue in Section 3.2 () 10300 * In Section 15.5.21, rephrase language not to use "entity" anymore, 10301 and also avoid lowercase "may" () 10304 * Move discussion of retries from [HTTP/1.1] into Section 9.2.2 10305 () 10307 C.7. Since draft-ietf-httpbis-semantics-05 10309 * Moved transport-independent part of the description of trailers 10310 into Section 6.5 () 10312 * Loosen requirements on retries based upon implementation behavior 10313 () 10315 * In Section 18.9, update IANA port registry for TCP/UDP on ports 80 10316 and 443 () 10318 * In Section 16.3.2.2, revise guidelines for new header field names 10319 () 10321 * In Section 9.2.3, remove concept of "cacheable methods" in favor 10322 of prose (, 10323 ) 10325 * In Section 17.1, mention that the concept of authority can be 10326 modified by protocol extensions () 10329 * Create new subsection on content in Section 6.4, taken from 10330 portions of message body () 10333 * Moved definition of "Whitespace" into new container "Generic 10334 Syntax" () 10336 * In Section 3.1, recommend minimum URI size support for 10337 implementations () 10339 * In Section 14.1, refactored the range-unit and ranges-specifier 10340 grammars (, 10341 ) 10343 * In Section 9.3.1, caution against a request content more strongly 10344 () 10346 * Reorganized text in Section 16.3.2.2 () 10349 * In Section 15.5.4, replace "authorize" with "fulfill" 10350 () 10352 * In Section 9.3.7, removed a misleading statement about Content- 10353 Length (, 10354 ) 10356 * In Section 17.1, add text from RFC 2818 10357 () 10359 * Changed "cacheable by default" to "heuristically cacheable" 10360 throughout () 10362 C.8. Since draft-ietf-httpbis-semantics-06 10364 * In Section 7.6.3, simplify received-by grammar (and disallow comma 10365 character) () 10367 * In Section 5.1, give guidance on interoperable field names 10368 () 10370 * In Section 5.6.3, define the semantics and possible replacement of 10371 whitespace when it is known to occur (, ) 10374 * In Section 6.3, introduce field terminology and distinguish 10375 between field line values and field values; use terminology 10376 consistently throughout () 10379 * Moved #rule definition into Section 5.5 and whitespace into 10380 Section 2.1 () 10382 * In Section 14.1, explicitly call out range unit names as case- 10383 insensitive, and encourage registration 10384 () 10386 * In Section 8.4.1, explicitly call out content codings as case- 10387 insensitive, and encourage registration 10388 () 10390 * In Section 5.1, explicitly call out field names as case- 10391 insensitive () 10393 * In Section 17.13, cite [Bujlow] () 10396 * In Section 15, formally define "final" and "interim" status codes 10397 () 10399 * In Section 9.3.5, caution against a request content more strongly 10400 () 10402 * In Section 8.8.3, note that Etag can be used in trailers 10403 () 10405 * In Section 18.4, consider reserved fields as well 10406 () 10408 * In Section 4.2.4, be more correct about what was deprecated by RFC 10409 3986 (, 10410 ) 10412 * In Section 5.3, recommend comma SP when combining field lines 10413 () 10415 * In Section 7.2, make explicit requirements on origin server to use 10416 authority from absolute-form when available 10417 () 10419 * In Section 4.2.1, Section 4.2.2, Section 4.3.1, and Section 7.3.3, 10420 refactored schemes to define origin and authoritative access to an 10421 origin server for both "http" and "https" URIs to account for 10422 alternative services and secured connections that are not 10423 necessarily based on TCP () 10426 * In Section 2.2, reference RFC 8174 as well 10427 () 10429 C.9. Since draft-ietf-httpbis-semantics-07 10431 * In Section 14.2, explicitly reference the definition of 10432 representation data as including any content codings 10433 () 10435 * Move TE: trailers from [HTTP/1.1] into Section 6.5.1 10436 () 10438 * In Section 8.6, adjust requirements for handling multiple content- 10439 length values () 10441 * In Section 13.1.1 and Section 13.1.2, clarified condition 10442 evaluation () 10444 * In Section 5.5, remove concept of obs-fold, as that is 10445 HTTP/1-specific () 10447 * In Section 12, introduce the concept of request content 10448 negotiation (Section 12.3) and define for Accept-Encoding 10449 () 10451 * In Section 15.3.6, Section 15.5.9, and Section 15.5.14, remove 10452 HTTP/1-specific, connection-related requirements 10453 () 10455 * In Section 9.3.6, correct language about what is forwarded 10456 () 10458 * Throughout, replace "effective request URI", "request-target" and 10459 similar with "target URI" () 10462 * In Section 16.3.2.2 and Section 16.2.2, describe how extensions 10463 should consider scope of applicability 10464 () 10466 * In Section 3.4, don't rely on the HTTP/1.1 Messaging specification 10467 to define "message" () 10470 * In Section 8.7 and Section 10.1.3, note that URL resolution is 10471 necessary () 10473 * In Section 3.2, explicitly reference 206 as one of the status 10474 codes that provide representation data 10475 () 10477 * In Section 13.1.4, refine requirements so that they don't apply to 10478 resources without a concept of modification time 10479 () 10481 * In Section 11.7.1, specify the scope as a request, not a target 10482 resource () 10484 * In Section 3.4, introduce concept of "complete" messages 10485 () 10487 * In Section 7.1, Section 9.3.6, and Section 9.3.7, refine use of 10488 "request target" () 10491 * Throughout, remove "status-line" and "request-line", as these are 10492 HTTP/1.1-specific () 10495 C.10. Since draft-ietf-httpbis-semantics-08 10497 * In Section 15.5.17, remove duplicate definition of what makes a 10498 range satisfiable and refer instead to each range unit's 10499 definition () 10501 * In Section 14.1.2 and Section 14.2, clarify that a selected 10502 representation of zero length can only be satisfiable as a suffix 10503 range and that a server can still ignore Range for that case 10504 () 10506 * In Section 12.5.1 and Section 15.5.16, allow "Accept" as response 10507 field () 10509 * Appendix A now uses the sender variant of the "#" list expansion 10510 () 10512 * In Section 12.5.5, make the field list-based even when "*" is 10513 present () 10515 * In Section 16.3.1, add optional "Comments" entry 10516 () 10518 * In Section 18.4, reserve "*" as field name 10519 () 10521 * In Section 18.2, reserve "*" as method name 10522 () 10524 * In Section 13.1.1 and Section 13.1.2, state that multiple "*" is 10525 unlikely to be interoperable () 10528 * In Section 12.5.1, avoid use of obsolete media type parameter on 10529 text/html (, 10530 ) 10532 * Rephrase prose in Section 3.4 to become version-agnostic 10533 () 10535 * In Section 5.5, instruct recipients how to deal with control 10536 characters in field values () 10539 * In Section 5.5, update note about field ABNF 10540 () 10542 * Add Section 16 about Extending and Versioning HTTP 10543 () 10545 * In Section 15.1, include status 308 in list of heuristically 10546 cacheable status codes () 10549 * In Section 8.4, make it clearer that "identity" is not to be 10550 included () 10552 C.11. Since draft-ietf-httpbis-semantics-09 10554 * Switch to xml2rfc v3 mode for draft generation 10555 () 10557 C.12. Since draft-ietf-httpbis-semantics-10 10559 * In Section 17.6, mention compression attacks 10560 () 10562 * In Section 16.6.1, advise to make new content codings self- 10563 descriptive () 10565 * In Section 5.6.6, introduced the "parameters" ABNF rule, allowing 10566 empty parameters and trailing semicolons within media type, media 10567 range, and expectation () 10570 * In Section 15.4, explain how to create a redirected request 10571 () 10573 * In Section 8.3, defined error handling for multiple members 10574 () 10576 * In Section 1, revise the introduction and introduce HTTP/2 and 10577 HTTP/3 () 10579 * In Section 8.6, added a definition for Content-Length that 10580 encompasses its various roles in describing message content or 10581 selected representation length; in Section 15.3.7, noted that 10582 Content-Length counts only the message content (not the selected 10583 representation) and that the representation length is in each 10584 Content-Range () 10586 * Noted that "WWW-Authenticate" with more than one value on a line 10587 is sometimes not interoperable [HTTP/1.1] 10588 () 10590 * In Section 13.1.1 and Section 13.1.4, removed requirement that a 10591 validator not be sent in a 2xx response when validation fails and 10592 the server decides that the same change request has already been 10593 applied () 10595 * Moved requirements specific to HTTP/1.1 from Section 7.2 to 10596 [HTTP/1.1] () 10598 * In Section 5.5, introduce the terms "singleton field" and "list- 10599 based field" (also - in various places - discuss what to do when a 10600 singleton field is received as a list) 10601 () 10603 * In Section 10.1.1, change the ABNF back to be a list of 10604 expectations, as defined in RFC 2616 () 10607 * In Section 10.1.5 (Trailer), Section 7.6.3 (Via), Section 7.8 10608 (Upgrade), Section 7.6.1 (Connection), Section 8.4 10609 (Content-Encoding), Section 8.5 (Content-Language), Section 10.1.1 10610 (Expect), Section 13.1.1 (If-Match), Section 13.1.2 10611 (If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4 10612 (Accept-Language), Section 12.5.5 (Vary), Section 11.6.1 10613 (WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate), 10614 adjust ABNF to allow empty lists () 10617 * In Section 9.3.1 and Section 17.9, provide a more nuanced 10618 explanation of sensitive data in GET-based forms and describe 10619 workarounds () 10621 * In Section 13.2, allow preconditions to be evaluated before the 10622 request content (if any) is processed () 10625 * In Section 6.3 and Section 6.5.2, allow for trailer fields in 10626 multiple trailer sections, depending on the HTTP version and 10627 framing in use, with processing being iterative as each section is 10628 received () 10630 * Moved definitions of "TE" and "Upgrade" from [HTTP/1.1] 10631 () 10633 * Moved 1.1-specific discussion of TLS to Messaging and rewrote 10634 Section 4.3.4 to refer to RFC6125 () 10637 * Moved definition of "Connection" from [HTTP/1.1] 10638 () 10640 C.13. Since draft-ietf-httpbis-semantics-11 10642 * The entire document has been reorganized, with no changes to 10643 content except editorial for the reorganization 10644 () 10646 * Move IANA Upgrade Token Registry instructions from [HTTP/1.1] 10647 () 10649 C.14. Since draft-ietf-httpbis-semantics-12 10651 * In Appendix "Acknowledgements" (Appendix "Acknowledgements"), 10652 added acks for the work since 2014 () 10655 * In Section 15.3.7, specifically require that a client check the 10656 206 response header fields to determine what ranges are enclosed, 10657 since it cannot assume they exactly match those requested 10658 () 10660 * In Section 16.3, explain why new fields need to be backwards- 10661 compatible () 10663 * In Section 5.3, constrain field combination to be within a section 10664 () 10666 * In Section 5.6.7, mention that caching relaxes date sensitivity 10667 () 10669 * In Section 18.4, moved "*" field registration into main table 10670 () 10672 * In Section 1.2, reference HTTP/0.9 () 10675 * In Section 9.3.4, clarify handling of unrecognized fields 10676 () 10678 * In Section 15.2, align language about bodies and trailers with 204 10679 and 304 () 10681 * Moved table of content codings into Section 18.6, moved table of 10682 range units into Section 18.7 () 10685 * In Section 6, add an abstract data type for message to help define 10686 semantics without being dependent on the specific structure of 10687 HTTP/1.1 () 10689 * In Section 8.8.2.2, relax arbitrary 60-second comparison limit 10690 () 10692 * In Section 7.2, add ":authority" pseudo-header to Host discussion 10693 and make section applicable to both () 10696 * In Section 18.4, note that this document updates [RFC3864] 10697 () 10699 * Moved transfer-coding ABNF from [HTTP/1.1] to Section 10.1.4 and 10700 replaced "t-ranking" ABNF by equivalent "weight" 10701 () 10703 * In Section 11.5, replace "canonical root URI" by "origin" 10704 () 10706 * In Section 10.1.1, remove obsolete note about a change in RFC 723x 10707 () 10709 * Changed to using "payload" when defining requirements about the 10710 data being conveyed within a message, instead of the terms 10711 "payload body" or "response body" or "representation body", since 10712 they often get confused with the HTTP/1.1 message body (which 10713 includes transfer coding) () 10716 * Rewrite definition of HEAD method () 10719 * In Section 13.1.5, fix an off-by-one bug about how many chars to 10720 consider when checking for etags () 10723 * In Section 15.1, clarify that "no reason phrase" is fine as well 10724 () 10726 * In Section 15.3.4, remove an obsolete reference to the Warning 10727 response header field () 10730 * In Section 15.5.9, rephrase prose about connection re-use 10731 () 10733 * In Section 14.2, potentially allow Range handling on methods other 10734 than GET () 10736 * In Section 18.3, remove redundant text about status code 418 10737 () 10739 * In Section 17.16.1, rewrite requirement to refer to "secured 10740 connection" () 10742 * Make reference to [TLS13] normative () 10745 C.15. Since draft-ietf-httpbis-semantics-13 10747 * In Section 12.5.1, remove the unused "accept parameters" 10748 () 10750 * In Section 1.2, mention that RFC 1945 describes HTTP/0.9 as well 10751 () 10753 * In Section 14.5, describe non-standard use of the Content-Range 10754 header field (Section 14.4) as a request modifier to perform a 10755 partial PUT () 10757 * In Section 15.5.20, import the 421 (Misdirected Request) status 10758 code from [HTTP/2] () 10761 * In Section 2.3, rephrase the actual recipient parsing requirements 10762 () 10764 * In Section 16.1.2, mention request target forms in considerations 10765 for new methods () 10767 * Changed to using "content" instead of "payload" or "payload data" 10768 to avoid confusion with the payload of version-specific messaging 10769 frames () 10771 * In Section 13.1.3, Section 13.1.4, and Section 13.1.5, specify 10772 evaluation in a way similar to other conditional header fields 10773 () 10775 * In Section 10.2.2, specify that recipients can replace an invalid 10776 Date header field value with the time received 10777 () 10779 C.16. Since draft-ietf-httpbis-semantics-14 10781 * In Section 5.5, relax prohibition of characters in field values to 10782 CR and NUL () 10784 * In Section 15, clarify that status code values outside the range 10785 100..599 are invalid, and recommend error handling 10786 () 10788 * In Section 2.2, replaced requirement on semantic conformance with 10789 permission to ignore/workaround implementation-specific failures 10790 () 10792 * Avoid the term "whitelist" () 10795 * In Section 9.3.8, remove the normative requirement to use the 10796 message/http media type () 10799 * In Section 7.6, discuss extensibility () 10802 * In Section 5.5, tighten the recommendation for characters in newly 10803 defined fields, making it consistent with obs-text 10804 () 10806 * In Section 5.5, leading/trailing whitespace removal is at time of 10807 use, not parsing () 10810 * In Section 6, clarify that HTTP self-descriptive messages have an 10811 exception in that the request must be understood in order to parse 10812 and interpret the response () 10815 * Remove "Canonicalization and Text Defaults" 10816 () 10818 * In Section 10.1.3, refine what can be sent in Referer, and when 10819 () 10821 * In Section 11.5, explain that the protection space is not defined 10822 without additional information () 10825 * Simplify description of reactive content negotiation in 10826 Section 12.2 () 10828 * In Section 8.3.2, remove the "charset" ABNF production, and 10829 clarify where charsets appear () 10832 * In Section 12.5.3, clarify that selection _between_ multiple 10833 acceptable codings is only relevant when they have the same 10834 purpose () 10836 * In Section 13, rewrite introduction, mentioning extensibility 10837 () 10839 * Throughout, be consistent about 'content coding' vs 'content- 10840 coding' () 10842 * In Section 9.3.6, clarify that the port is mandatory in a CONNECT 10843 request target () 10844 and that the tunnel begins after the header section 10845 () 10847 * In Section 6.5, remove mid-stream trailers 10848 () 10850 * In Section 3.3, clarify duplexing semantics 10851 () 10853 * In Section 3.3, explain the implications of statelessness more 10854 clearly () 10856 * In Section 8.6, be more explicit about invalid and incorrect 10857 values ( and 10858 ) 10860 * Move discussion of statelessness from Section 3.7 to Section 3.3 10861 () 10863 * In Section 15.2.2, clarify that the upgraded protocol is in effect 10864 after the 101 response () 10867 * In Section 9.3.6, state that data received after the headers of a 10868 CONNECT message is version-specific () 10871 * In Section 4.2.3, clarify how normalization works, and align with 10872 RF3986 () 10874 * In Section 10.1.5, note that the Trailer field can be used to 10875 discover deleted trailers () 10878 * Throughout, remove unneeded normative references to [HTTP/1.1] 10879 () 10881 * In Section 10.1.4, explicitly require listing in Connection 10882 () 10884 C.17. Since draft-ietf-httpbis-semantics-15 10886 * For [HTTP/3], add an RFC Editor note to rename to "RFCnnn" before 10887 publication () 10889 * In Section 9.3.2, align prose about content in HEAD requests with 10890 description of GET () 10893 * In Section 5.3, remove the restriction to non-empty field line 10894 values () 10896 * Add forward references to definition of OWS 10897 () 10899 * In Section 17.10, add a security consideration regarding 10900 application handling of field names () 10903 C.18. Since draft-ietf-httpbis-semantics-16 10905 This draft addresses mostly editorial issues raised during or past 10906 IETF Last Call; see for a summary. 10909 Furthermore: 10911 * In Section 15.3.7, reinstate 'to a request' 10912 () 10914 * Align Section 16.3.1 with Section 16.3.2.1 10915 () 10917 * In Section 14.3, clarify that Accept-Ranges can be sent by any 10918 server, remove "none" from the ABNF because it is now a reserved 10919 range unit, and allow the field to be sent in a trailer section 10920 while noting why that is much less useful than as a header field 10921 () 10923 * In Section 7.6.3, don't specify TCP () 10926 * In Section 6.4, explain the "Content-" prefix 10927 () 10929 * In Section 7.4, check all target URIs for scheme semantic 10930 mismatches () 10932 * In Section 9.3.1, Section 9.3.2, and Section 9.3.5, clarify 10933 (again) that sending content in a request for a method that does 10934 not define such content will not interoperate without prior 10935 agreement, even if it is parsed correctly, and cannot be relied 10936 upon by an origin server unless they control the entire request 10937 chain () 10939 Acknowledgements 10941 Aside from the current editors, the following individuals deserve 10942 special recognition for their contributions to early aspects of HTTP 10943 and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert 10944 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, 10945 Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery 10946 L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott 10947 D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry 10948 Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, 10949 Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders, 10950 Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles. 10952 This edition builds on the many contributions that went into past 10953 specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC 10954 2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 10955 7234, and RFC 7235. The acknowledgements within those documents 10956 still apply. 10958 Since 2014, the following contributors have helped improve this 10959 specification by reporting bugs, asking smart questions, drafting or 10960 reviewing text, and evaluating open issues: 10962 Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders 10963 Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron 10964 Duby, Asanka Herath, Asbjørn Ulsberg, Asta Olofsson, Attila Gulyas, 10965 Austin Wright, Barry Pollard, Ben Burkert, Benjamin Kaduk, Björn 10966 Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory 10967 Benfield, Cory Nelson, Daisuke Miyakawa, Dale Worley, Daniel 10968 Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi, 10969 Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla, Éric 10970 Vyncke, Erik Kline, Erwin Pe, Etan Kissling, Evert Pot, Evgeny 10971 Vrublevsky, Florian Best, Francesca Palombini, Igor Lubashev, James 10972 Callahan, James Peach, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan, 10973 奥 一穂 (Kazuho Oku), Ken Murchison, Krzysztof Maczyński, Lars Eggert, 10974 Lucas Pardue, Martin Duke, Martin Dürst, Martin Thomson, Martynas 10975 Jusevičius, Matt Menke, Matthias Pigulla, Mattias Grenfeldt, Michael 10976 Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Mohit 10977 Sethi, Murray Kucherawy, Nathaniel J. Smith, Nicholas Hurley, Nikita 10978 Prokhorov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van 10979 Rein, Robert Wilton, Roberto Polli, Roman Danyliw, Samuel Williams, 10980 Semyon Kholodnov, Simon Pieters, Simon Schüppel, Stefan Eissing, 10981 Taylor Hunt, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir 10982 Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu, 10983 Yishuai Li, and Zaheduzzaman Sarker. 10985 Index 10987 1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X 10989 1 10991 100 Continue (status code) Section 15.2.1 10992 100-continue (expect value) Section 10.1.1 10993 101 Switching Protocols (status code) Section 15.2.2 10994 1xx Informational (status code class) Section 15.2 10996 2 10998 200 OK (status code) Section 15.3.1 10999 201 Created (status code) Section 15.3.2 11000 202 Accepted (status code) Section 15.3.3 11001 203 Non-Authoritative Information (status code) Section 15.3.4 11002 204 No Content (status code) Section 15.3.5 11003 205 Reset Content (status code) Section 15.3.6 11004 206 Partial Content (status code) Section 15.3.7 11005 2xx Successful (status code class) Section 15.3 11007 3 11009 300 Multiple Choices (status code) Section 15.4.1 11010 301 Moved Permanently (status code) Section 15.4.2 11011 302 Found (status code) Section 15.4.3 11012 303 See Other (status code) Section 15.4.4 11013 304 Not Modified (status code) Section 15.4.5 11014 305 Use Proxy (status code) Section 15.4.6 11015 306 (Unused) (status code) Section 15.4.7 11016 307 Temporary Redirect (status code) Section 15.4.8 11017 308 Permanent Redirect (status code) Section 15.4.9 11018 3xx Redirection (status code class) Section 15.4 11020 4 11022 400 Bad Request (status code) Section 15.5.1 11023 401 Unauthorized (status code) Section 15.5.2 11024 402 Payment Required (status code) Section 15.5.3 11025 403 Forbidden (status code) Section 15.5.4 11026 404 Not Found (status code) Section 15.5.5 11027 405 Method Not Allowed (status code) Section 15.5.6 11028 406 Not Acceptable (status code) Section 15.5.7 11029 407 Proxy Authentication Required (status code) Section 15.5.8 11030 408 Request Timeout (status code) Section 15.5.9 11031 409 Conflict (status code) Section 15.5.10 11032 410 Gone (status code) Section 15.5.11 11033 411 Length Required (status code) Section 15.5.12 11034 412 Precondition Failed (status code) Section 15.5.13 11035 413 Content Too Large (status code) Section 15.5.14 11036 414 URI Too Long (status code) Section 15.5.15 11037 415 Unsupported Media Type (status code) Section 15.5.16 11038 416 Range Not Satisfiable (status code) Section 15.5.17 11039 417 Expectation Failed (status code) Section 15.5.18 11040 418 (Unused) (status code) Section 15.5.19 11041 421 Misdirected Request (status code) Section 15.5.20 11042 422 Unprocessable Content (status code) Section 15.5.21 11043 426 Upgrade Required (status code) Section 15.5.22 11044 4xx Client Error (status code class) Section 15.5 11046 5 11048 500 Internal Server Error (status code) Section 15.6.1 11049 501 Not Implemented (status code) Section 15.6.2 11050 502 Bad Gateway (status code) Section 15.6.3 11051 503 Service Unavailable (status code) Section 15.6.4 11052 504 Gateway Timeout (status code) Section 15.6.5 11053 505 HTTP Version Not Supported (status code) Section 15.6.6 11054 5xx Server Error (status code class) Section 15.6 11056 A 11058 Accept header field Section 12.5.1 11059 Accept-Charset header field Section 12.5.2 11060 Accept-Encoding header field Section 12.5.3 11061 Accept-Language header field Section 12.5.4 11062 Accept-Ranges header field Section 14.3 11063 Allow header field Section 10.2.1 11064 Authentication-Info header field Section 11.6.3 11065 Authorization header field Section 11.6.2 11066 accelerator Section 3.7, Paragraph 6 11067 authoritative response Section 17.1 11069 B 11071 browser Section 3.5 11073 C 11075 CONNECT method Section 9.3.6 11076 Connection header field Section 7.6.1 11077 Content-Encoding header field Section 8.4 11078 Content-Language header field Section 8.5 11079 Content-Length header field Section 8.6 11080 Content-Location header field Section 8.7 11081 Content-MD5 header field Section 18.4, Paragraph 9 11082 Content-Range header field Section 14.4; Section 14.5 11083 Content-Type header field Section 8.3 11084 cache Section 3.8 11085 cacheable Section 3.8, Paragraph 4 11086 client Section 3.3 11087 complete Section 6.1 11088 compress (Coding Format) Section 8.4.1.1 11089 compress (content coding) Section 8.4.1 11090 conditional request Section 13 11091 connection Section 3.3 11092 content Section 6.4 11093 content coding Section 8.4.1 11094 content negotiation Section 1.3, Paragraph 4 11095 control data Section 6.2 11097 D 11099 DELETE method Section 9.3.5 11100 Date header field Section 10.2.2 11101 Delimiters Section 5.6.2, Paragraph 3 11102 deflate (Coding Format) Section 8.4.1.2 11103 deflate (content coding) Section 8.4.1 11104 downstream Section 3.7, Paragraph 4 11106 E 11108 ETag field Section 8.8.3 11109 Expect header field Section 10.1.1 11110 effective request URI Section 7.1, Paragraph 8.1 11112 F 11114 Fields 11115 * Section 18.4, Paragraph 8 11116 Accept Section 12.5.1 11117 Accept-Charset Section 12.5.2 11118 Accept-Encoding Section 12.5.3 11119 Accept-Language Section 12.5.4 11120 Accept-Ranges Section 14.3 11121 Allow Section 10.2.1 11122 Authentication-Info Section 11.6.3 11123 Authorization Section 11.6.2 11124 Connection Section 7.6.1 11125 Content-Encoding Section 8.4 11126 Content-Language Section 8.5 11127 Content-Length Section 8.6 11128 Content-Location Section 8.7 11129 Content-MD5 Section 18.4, Paragraph 9 11130 Content-Range Section 14.4; Section 14.5 11131 Content-Type Section 8.3 11132 Date Section 10.2.2 11133 ETag Section 8.8.3 11134 Expect Section 10.1.1 11135 From Section 10.1.2 11136 Host Section 7.2 11137 If-Match Section 13.1.1 11138 If-Modified-Since Section 13.1.3 11139 If-None-Match Section 13.1.2 11140 If-Range Section 13.1.5 11141 If-Unmodified-Since Section 13.1.4 11142 Last-Modified Section 8.8.2 11143 Location Section 10.2.3 11144 Max-Forwards Section 7.6.2 11145 Proxy-Authenticate Section 11.7.1 11146 Proxy-Authentication-Info Section 11.7.3 11147 Proxy-Authorization Section 11.7.2 11148 Range Section 14.2 11149 Referer Section 10.1.3 11150 Retry-After Section 10.2.4 11151 Server Section 10.2.5 11152 TE Section 10.1.4 11153 Trailer Section 10.1.5 11154 Upgrade Section 7.8 11155 User-Agent Section 10.1.6 11156 Vary Section 12.5.5 11157 Via Section 7.6.3 11158 WWW-Authenticate Section 11.6.1 11159 Fragment Identifiers Section 4.2.5 11160 From header field Section 10.1.2 11161 field Section 5; Section 6.3 11162 field line Section 5.2, Paragraph 1 11163 field line value Section 5.2, Paragraph 1 11164 field name Section 5.2, Paragraph 1 11165 field value Section 5.2, Paragraph 2 11167 G 11169 GET method Section 9.3.1 11170 Grammar 11171 ALPHA Section 2.1 11172 Accept Section 12.5.1 11173 Accept-Charset Section 12.5.2 11174 Accept-Encoding Section 12.5.3 11175 Accept-Language Section 12.5.4 11176 Accept-Ranges Section 14.3 11177 Allow Section 10.2.1 11178 Authentication-Info Section 11.6.3 11179 Authorization Section 11.6.2 11180 BWS Section 5.6.3 11181 CR Section 2.1 11182 CRLF Section 2.1 11183 CTL Section 2.1 11184 Connection Section 7.6.1 11185 Content-Encoding Section 8.4 11186 Content-Language Section 8.5 11187 Content-Length Section 8.6 11188 Content-Location Section 8.7 11189 Content-Range Section 14.4 11190 Content-Type Section 8.3 11191 DIGIT Section 2.1 11192 DQUOTE Section 2.1 11193 Date Section 10.2.2 11194 ETag Section 8.8.3 11195 Expect Section 10.1.1 11196 From Section 10.1.2 11197 GMT Section 5.6.7 11198 HEXDIG Section 2.1 11199 HTAB Section 2.1 11200 HTTP-date Section 5.6.7 11201 Host Section 7.2 11202 IMF-fixdate Section 5.6.7 11203 If-Match Section 13.1.1 11204 If-Modified-Since Section 13.1.3 11205 If-None-Match Section 13.1.2 11206 If-Range Section 13.1.5 11207 If-Unmodified-Since Section 13.1.4 11208 LF Section 2.1 11209 Last-Modified Section 8.8.2 11210 Location Section 10.2.3 11211 Max-Forwards Section 7.6.2 11212 OCTET Section 2.1 11213 OWS Section 5.6.3 11214 Proxy-Authenticate Section 11.7.1 11215 Proxy-Authentication-Info Section 11.7.3 11216 Proxy-Authorization Section 11.7.2 11217 RWS Section 5.6.3 11218 Range Section 14.2 11219 Referer Section 10.1.3 11220 Retry-After Section 10.2.4 11221 SP Section 2.1 11222 Server Section 10.2.5 11223 TE Section 10.1.4 11224 Trailer Section 10.1.5 11225 URI-reference Section 4.1 11226 Upgrade Section 7.8 11227 User-Agent Section 10.1.6 11228 VCHAR Section 2.1 11229 Vary Section 12.5.5 11230 Via Section 7.6.3 11231 WWW-Authenticate Section 11.6.1 11232 absolute-URI Section 4.1 11233 absolute-path Section 4.1 11234 acceptable-ranges Section 14.3 11235 asctime-date Section 5.6.7 11236 auth-param Section 11.2 11237 auth-scheme Section 11.1 11238 authority Section 4.1 11239 challenge Section 11.3 11240 codings Section 12.5.3 11241 comment Section 5.6.5 11242 complete-length Section 14.4 11243 connection-option Section 7.6.1 11244 content-coding Section 8.4.1 11245 credentials Section 11.4 11246 ctext Section 5.6.5 11247 date1 Section 5.6.7 11248 day Section 5.6.7 11249 day-name Section 5.6.7 11250 day-name-l Section 5.6.7 11251 delay-seconds Section 10.2.4 11252 entity-tag Section 8.8.3 11253 etagc Section 8.8.3 11254 field-content Section 5.5 11255 field-name Section 5.1; Section 10.1.5 11256 field-value Section 5.5 11257 field-vchar Section 5.5 11258 first-pos Section 14.1.1; Section 14.4 11259 hour Section 5.6.7 11260 http-URI Section 4.2.1 11261 https-URI Section 4.2.2 11262 incl-range Section 14.4 11263 int-range Section 14.1.1 11264 language-range Section 12.5.4 11265 language-tag Section 8.5.1 11266 last-pos Section 14.1.1; Section 14.4 11267 media-range Section 12.5.1 11268 media-type Section 8.3.1 11269 method Section 9.1 11270 minute Section 5.6.7 11271 month Section 5.6.7 11272 obs-date Section 5.6.7 11273 obs-text Section 5.6.4 11274 opaque-tag Section 8.8.3 11275 other-range Section 14.1.1 11276 parameter Section 5.6.6 11277 parameter-name Section 5.6.6 11278 parameter-value Section 5.6.6 11279 parameters Section 5.6.6 11280 partial-URI Section 4.1 11281 port Section 4.1 11282 product Section 10.1.6 11283 product-version Section 10.1.6 11284 protocol-name Section 7.6.3 11285 protocol-version Section 7.6.3 11286 pseudonym Section 7.6.3 11287 qdtext Section 5.6.4 11288 query Section 4.1 11289 quoted-pair Section 5.6.4 11290 quoted-string Section 5.6.4 11291 qvalue Section 12.4.2 11292 range-resp Section 14.4 11293 range-set Section 14.1.1 11294 range-spec Section 14.1.1 11295 range-unit Section 14.1 11296 ranges-specifier Section 14.1.1 11297 received-by Section 7.6.3 11298 received-protocol Section 7.6.3 11299 rfc850-date Section 5.6.7 11300 second Section 5.6.7 11301 segment Section 4.1 11302 subtype Section 8.3.1 11303 suffix-length Section 14.1.1 11304 suffix-range Section 14.1.1 11305 t-codings Section 10.1.4 11306 tchar Section 5.6.2 11307 time-of-day Section 5.6.7 11308 token Section 5.6.2 11309 token68 Section 11.2 11310 transfer-coding Section 10.1.4 11311 transfer-parameter Section 10.1.4 11312 type Section 8.3.1 11313 unsatisfied-range Section 14.4 11314 uri-host Section 4.1 11315 weak Section 8.8.3 11316 weight Section 12.4.2 11317 year Section 5.6.7 11318 gateway Section 3.7, Paragraph 6 11319 gzip (Coding Format) Section 8.4.1.3 11320 gzip (content coding) Section 8.4.1 11322 H 11324 HEAD method Section 9.3.2 11325 Header Fields 11326 Accept Section 12.5.1 11327 Accept-Charset Section 12.5.2 11328 Accept-Encoding Section 12.5.3 11329 Accept-Language Section 12.5.4 11330 Accept-Ranges Section 14.3 11331 Allow Section 10.2.1 11332 Authentication-Info Section 11.6.3 11333 Authorization Section 11.6.2 11334 Connection Section 7.6.1 11335 Content-Encoding Section 8.4 11336 Content-Language Section 8.5 11337 Content-Length Section 8.6 11338 Content-Location Section 8.7 11339 Content-MD5 Section 18.4, Paragraph 9 11340 Content-Range Section 14.4; Section 14.5 11341 Content-Type Section 8.3 11342 Date Section 10.2.2 11343 ETag Section 8.8.3 11344 Expect Section 10.1.1 11345 From Section 10.1.2 11346 Host Section 7.2 11347 If-Match Section 13.1.1 11348 If-Modified-Since Section 13.1.3 11349 If-None-Match Section 13.1.2 11350 If-Range Section 13.1.5 11351 If-Unmodified-Since Section 13.1.4 11352 Last-Modified Section 8.8.2 11353 Location Section 10.2.3 11354 Max-Forwards Section 7.6.2 11355 Proxy-Authenticate Section 11.7.1 11356 Proxy-Authentication-Info Section 11.7.3 11357 Proxy-Authorization Section 11.7.2 11358 Range Section 14.2 11359 Referer Section 10.1.3 11360 Retry-After Section 10.2.4 11361 Server Section 10.2.5 11362 TE Section 10.1.4 11363 Trailer Section 10.1.5 11364 Upgrade Section 7.8 11365 User-Agent Section 10.1.6 11366 Vary Section 12.5.5 11367 Via Section 7.6.3 11368 WWW-Authenticate Section 11.6.1 11369 Host header field Section 7.2 11370 header section Section 6.3 11371 http URI scheme Section 4.2.1 11372 https URI scheme Section 4.2.2 11374 I 11376 If-Match header field Section 13.1.1 11377 If-Modified-Since header field Section 13.1.3 11378 If-None-Match header field Section 13.1.2 11379 If-Range header field Section 13.1.5 11380 If-Unmodified-Since header field Section 13.1.4 11381 idempotent Section 9.2.2 11382 inbound Section 3.7, Paragraph 4 11383 incomplete Section 6.1 11384 interception proxy Section 3.7, Paragraph 10 11385 intermediary Section 3.7 11387 L 11389 Last-Modified header field Section 8.8.2 11390 Location header field Section 10.2.3 11391 list-based field Section 5.5, Paragraph 7 11393 M 11395 Max-Forwards header field Section 7.6.2 11396 Media Type 11397 multipart/byteranges Section 14.6 11398 multipart/x-byteranges Section 14.6, Paragraph 4, Item 3 11399 Method 11400 * Section 18.2, Paragraph 3 11401 CONNECT Section 9.3.6 11402 DELETE Section 9.3.5 11403 GET Section 9.3.1 11404 HEAD Section 9.3.2 11405 OPTIONS Section 9.3.7 11406 POST Section 9.3.3 11407 PUT Section 9.3.4 11408 TRACE Section 9.3.8 11409 message Section 3.4; Section 6 11410 message abstraction Section 6 11411 messages Section 3.4 11412 metadata Section 8.8 11413 multipart/byteranges Media Type Section 14.6 11414 multipart/x-byteranges Media Type Section 14.6, Paragraph 4, 11415 Item 3 11417 N 11419 non-transforming proxy Section 7.7 11421 O 11423 OPTIONS method Section 9.3.7 11424 Origin Section 11.5 11425 origin Section 4.3.1 11426 origin server Section 3.6 11427 outbound Section 3.7, Paragraph 4 11429 P 11431 POST method Section 9.3.3 11432 PUT method Section 9.3.4 11433 Protection Space Section 11.5 11434 Proxy-Authenticate header field Section 11.7.1 11435 Proxy-Authentication-Info header field Section 11.7.3 11436 Proxy-Authorization header field Section 11.7.2 11437 phishing Section 17.1 11438 proxy Section 3.7, Paragraph 5 11440 R 11442 Range header field Section 14.2 11443 Realm Section 11.5 11444 Referer header field Section 10.1.3 11445 Retry-After header field Section 10.2.4 11446 recipient Section 3.4 11447 representation Section 3.2 11448 request Section 3.4 11449 request target Section 7.1 11450 resource Section 3.1; Section 4 11451 response Section 3.4 11452 reverse proxy Section 3.7, Paragraph 6 11454 S 11456 Server header field Section 10.2.5 11457 Status Code Section 15 11458 Status Codes 11459 Final Section 15, Paragraph 7 11460 Informational Section 15, Paragraph 7 11461 Interim Section 15, Paragraph 7 11462 Status Codes Classes 11463 1xx Informational Section 15.2 11464 2xx Successful Section 15.3 11465 3xx Redirection Section 15.4 11466 4xx Client Error Section 15.5 11467 5xx Server Error Section 15.6 11468 safe Section 9.2.1 11469 secured Section 4.2.2 11470 selected representation Section 3.2, Paragraph 4; Section 8.8; 11471 Section 13.1 11472 self-descriptive Section 6 11473 sender Section 3.4 11474 server Section 3.3 11475 singleton field Section 5.5, Paragraph 6 11476 spider Section 3.5 11478 T 11480 TE header field Section 10.1.4 11481 TRACE method Section 9.3.8 11482 Trailer Fields 11483 ETag Section 8.8.3 11484 Trailer header field Section 10.1.5 11485 target URI Section 7.1 11486 target resource Section 7.1 11487 trailer fields Section 6.5 11488 trailer section Section 6.5 11489 trailers Section 6.5 11490 transforming proxy Section 7.7 11491 transparent proxy Section 3.7, Paragraph 10 11492 tunnel Section 3.7, Paragraph 8 11494 U 11496 URI Section 4 11497 origin Section 4.3.1 11498 URI reference Section 4.1 11499 URI scheme 11500 http Section 4.2.1 11501 https Section 4.2.2 11502 Upgrade header field Section 7.8 11503 User-Agent header field Section 10.1.6 11504 upstream Section 3.7, Paragraph 4 11505 user agent Section 3.5 11507 V 11509 Vary header field Section 12.5.5 11510 Via header field Section 7.6.3 11511 validator Section 8.8 11512 strong Section 8.8.1 11513 weak Section 8.8.1 11515 W 11517 WWW-Authenticate header field Section 11.6.1 11519 X 11521 x-compress (content coding) Section 8.4.1 11522 x-gzip (content coding) Section 8.4.1 11524 Authors' Addresses 11525 Roy T. Fielding (editor) 11526 Adobe 11527 345 Park Ave 11528 San Jose, CA 95110 11529 United States of America 11531 Email: fielding@gbiv.com 11532 URI: https://roy.gbiv.com/ 11534 Mark Nottingham (editor) 11535 Fastly 11536 Prahran VIC 11537 Australia 11539 Email: mnot@mnot.net 11540 URI: https://www.mnot.net/ 11542 Julian Reschke (editor) 11543 greenbytes GmbH 11544 Hafenweg 16 11545 48155 Münster 11546 Germany 11548 Email: julian.reschke@greenbytes.de 11549 URI: https://greenbytes.de/tech/webdav/