idnits 2.17.1 draft-ietf-httpbis-p2-semantics-14.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- 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 (April 18, 2011) is 4750 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-14 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-14 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- 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 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: October 20, 2011 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 April 18, 2011 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-14 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypermedia information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 2 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 33 the semantics of HTTP messages as expressed by request methods, 34 request header fields, response status codes, and response header 35 fields. 37 Editorial Note (To be removed by RFC Editor) 39 Discussion of this draft should take place on the HTTPBIS working 40 group mailing list (ietf-http-wg@w3.org), which is archived at 41 . 43 The current issues list is at 44 and related 45 documents (including fancy diffs) can be found at 46 . 48 The changes in this draft are summarized in Appendix C.15. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on October 20, 2011. 67 Copyright Notice 69 Copyright (c) 2011 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 This document may contain material from IETF Documents or IETF 83 Contributions published or made publicly available before November 84 10, 2008. The person(s) controlling the copyright in some of this 85 material may not have granted the IETF Trust the right to allow 86 modifications of such material outside the IETF Standards Process. 87 Without obtaining an adequate license from the person(s) controlling 88 the copyright in such materials, this document may not be modified 89 outside the IETF Standards Process, and derivative works of it may 90 not be created outside the IETF Standards Process, except to format 91 it for publication as an RFC or to translate it into languages other 92 than English. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 99 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 100 1.2.2. ABNF Rules defined in other Parts of the 101 Specification . . . . . . . . . . . . . . . . . . . . 7 102 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 103 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 104 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 105 2.2.1. Considerations for New Methods . . . . . . . . . . . . 8 106 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 107 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 108 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 10 109 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 110 4.2.1. Considerations for New Status Codes . . . . . . . . . 12 111 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13 112 6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13 113 6.1. Identifying the Resource Associated with a 114 Representation . . . . . . . . . . . . . . . . . . . . . . 13 115 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 116 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 117 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 118 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15 119 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 120 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 121 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 122 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 123 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 124 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 125 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 126 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21 127 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22 128 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 23 129 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 23 130 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23 131 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23 132 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 24 133 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 24 134 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24 135 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 25 136 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25 137 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25 138 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 26 139 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26 140 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26 141 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 27 142 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27 143 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 28 144 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28 145 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 29 146 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29 147 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29 148 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29 149 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 30 150 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30 151 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30 152 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30 153 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30 154 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 31 155 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 31 156 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 31 157 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 32 158 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 32 159 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 32 160 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32 161 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 33 162 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 33 163 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 33 164 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33 165 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33 166 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 34 167 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 34 168 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 34 169 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34 170 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34 171 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 35 172 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 35 173 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 35 174 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35 175 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35 176 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36 177 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 36 178 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36 179 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 180 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 38 181 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 39 182 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39 183 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 40 184 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40 185 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 41 186 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 187 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41 188 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42 189 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43 190 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 191 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44 192 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45 193 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46 194 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46 195 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 196 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 197 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 198 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 199 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48 200 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 201 Appendix C. Change Log (to be removed by RFC Editor before 202 publication) . . . . . . . . . . . . . . . . . . . . 51 203 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 51 204 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 51 205 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 52 206 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52 207 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 53 208 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53 209 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54 210 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54 211 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 212 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55 213 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 214 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 215 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56 216 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 217 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58 218 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 220 1. Introduction 222 This document defines HTTP/1.1 request and response semantics. Each 223 HTTP message, as defined in [Part1], is in the form of either a 224 request or a response. An HTTP server listens on a connection for 225 HTTP requests and responds to each request, in the order received on 226 that connection, with one or more HTTP response messages. This 227 document defines the commonly agreed upon semantics of the HTTP 228 uniform interface, the intentions defined by each request method, and 229 the various response messages that might be expected as a result of 230 applying that method to the target resource. 232 This document is currently disorganized in order to minimize the 233 changes between drafts and enable reviewers to see the smaller errata 234 changes. A future draft will reorganize the sections to better 235 reflect the content. In particular, the sections will be ordered 236 according to the typical processing of an HTTP request message (after 237 message parsing): resource mapping, methods, request modifying header 238 fields, response status, status modifying header fields, and resource 239 metadata. The current mess reflects how widely dispersed these 240 topics and associated requirements had become in [RFC2616]. 242 1.1. Requirements 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 An implementation is not compliant if it fails to satisfy one or more 249 of the "MUST" or "REQUIRED" level requirements for the protocols it 250 implements. An implementation that satisfies all the "MUST" or 251 "REQUIRED" level and all the "SHOULD" level requirements for its 252 protocols is said to be "unconditionally compliant"; one that 253 satisfies all the "MUST" level requirements but not all the "SHOULD" 254 level requirements for its protocols is said to be "conditionally 255 compliant". 257 1.2. Syntax Notation 259 This specification uses the ABNF syntax defined in Section 1.2 of 260 [Part1] (which extends the syntax defined in [RFC5234] with a list 261 rule). Appendix B shows the collected ABNF, with the list rule 262 expanded. 264 The following core rules are included by reference, as defined in 265 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 266 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 267 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 268 sequence of data), SP (space), VCHAR (any visible USASCII character), 269 and WSP (whitespace). 271 1.2.1. Core Rules 273 The core rules below are defined in Section 1.2.2 of [Part1]: 275 quoted-string = 276 token = 277 OWS = 278 RWS = 279 obs-text = 281 1.2.2. ABNF Rules defined in other Parts of the Specification 283 The ABNF rules below are defined in other parts: 285 absolute-URI = 286 comment = 287 HTTP-date = 288 partial-URI = 289 product = 290 URI-reference = 292 2. Method 294 The Method token indicates the request method to be performed on the 295 target resource (Section 4.3 of [Part1]). The method is case- 296 sensitive. 298 Method = token 300 The list of methods allowed by a resource can be specified in an 301 Allow header field (Section 9.1). The status code of the response 302 always notifies the client whether a method is currently allowed on a 303 resource, since the set of allowed methods can change dynamically. 304 An origin server SHOULD respond with the status code 405 (Method Not 305 Allowed) if the method is known by the origin server but not allowed 306 for the resource, and 501 (Not Implemented) if the method is 307 unrecognized or not implemented by the origin server. The methods 308 GET and HEAD MUST be supported by all general-purpose servers. All 309 other methods are OPTIONAL; however, if the above methods are 310 implemented, they MUST be implemented with the same semantics as 311 those specified in Section 7. 313 2.1. Overview of Methods 315 The methods listed below are defined in Section 7. 317 +-------------+---------------+ 318 | Method Name | Defined in... | 319 +-------------+---------------+ 320 | OPTIONS | Section 7.2 | 321 | GET | Section 7.3 | 322 | HEAD | Section 7.4 | 323 | POST | Section 7.5 | 324 | PUT | Section 7.6 | 325 | DELETE | Section 7.7 | 326 | TRACE | Section 7.8 | 327 | CONNECT | Section 7.9 | 328 +-------------+---------------+ 330 Note that this list is not exhaustive -- it does not include request 331 methods defined in other specifications. 333 2.2. Method Registry 335 The HTTP Method Registry defines the name space for the Method token 336 in the Request line of an HTTP request. 338 Registrations MUST include the following fields: 340 o Method Name (see Section 2) 342 o Safe ("yes" or "no", see Section 7.1.1) 344 o Pointer to specification text 346 Values to be added to this name space are subject to IETF review 347 ([RFC5226], Section 4.1). 349 The registry itself is maintained at 350 . 352 2.2.1. Considerations for New Methods 354 When it is necessary to express new semantics for a HTTP request that 355 aren't specific to a single application or media type, and currently 356 defined methods are inadequate, it may be appropriate to register a 357 new method. 359 HTTP methods are generic; that is, they are potentially applicable to 360 any resource, not just one particular media type, "type" of resource, 361 or application. As such, it is preferred that new HTTP methods be 362 registered in a document that isn't specific to a single application, 363 so that this is clear. 365 Due to the parsing rules defined in Section 3.3 of [Part1], 366 definitions of HTTP methods cannot prohibit the presence of a 367 message-body on either the request or the response message (with 368 responses to HEAD requests being the single exception). Definitions 369 of new methods cannot change this rule, but they can specify that 370 only zero-length bodies (as opposed to absent bodies) are allowed. 372 New method definitions need to indicate whether they are safe 373 (Section 7.1.1), what semantics (if any) the request body has, and 374 whether they are idempotent (Section 7.1.2). They also need to state 375 whether they can be cached ([Part6]); in particular what conditions a 376 cache may store the response, and under what conditions such a stored 377 response may be used to satisfy a subsequent request. 379 3. Request Header Fields 381 The request header fields allow the client to pass additional 382 information about the request, and about the client itself, to the 383 server. These fields act as request modifiers, with semantics 384 equivalent to the parameters on a programming language method 385 invocation. 387 +---------------------+------------------------+ 388 | Header Field Name | Defined in... | 389 +---------------------+------------------------+ 390 | Accept | Section 6.1 of [Part3] | 391 | Accept-Charset | Section 6.2 of [Part3] | 392 | Accept-Encoding | Section 6.3 of [Part3] | 393 | Accept-Language | Section 6.4 of [Part3] | 394 | Authorization | Section 4.1 of [Part7] | 395 | Expect | Section 9.2 | 396 | From | Section 9.3 | 397 | Host | Section 9.4 of [Part1] | 398 | If-Match | Section 3.1 of [Part4] | 399 | If-Modified-Since | Section 3.3 of [Part4] | 400 | If-None-Match | Section 3.2 of [Part4] | 401 | If-Range | Section 5.3 of [Part5] | 402 | If-Unmodified-Since | Section 3.4 of [Part4] | 403 | Max-Forwards | Section 9.5 | 404 | Proxy-Authorization | Section 4.3 of [Part7] | 405 | Range | Section 5.4 of [Part5] | 406 | Referer | Section 9.6 | 407 | TE | Section 9.5 of [Part1] | 408 | User-Agent | Section 9.9 | 409 +---------------------+------------------------+ 411 4. Status Code and Reason Phrase 413 The Status-Code element is a 3-digit integer result code of the 414 attempt to understand and satisfy the request. 416 The Reason-Phrase is intended to give a short textual description of 417 the Status-Code and is intended for a human user. The client does 418 not need to examine or display the Reason-Phrase. 420 Status-Code = 3DIGIT 421 Reason-Phrase = *( WSP / VCHAR / obs-text ) 423 HTTP status codes are extensible. HTTP applications are not required 424 to understand the meaning of all registered status codes, though such 425 understanding is obviously desirable. However, applications MUST 426 understand the class of any status code, as indicated by the first 427 digit, and treat any unrecognized response as being equivalent to the 428 x00 status code of that class, with the exception that an 429 unrecognized response MUST NOT be cached. For example, if an 430 unrecognized status code of 431 is received by the client, it can 431 safely assume that there was something wrong with its request and 432 treat the response as if it had received a 400 status code. In such 433 cases, user agents SHOULD present to the user the representation 434 enclosed with the response, since that representation is likely to 435 include human-readable information which will explain the unusual 436 status. 438 4.1. Overview of Status Codes 440 The status codes listed below are defined in Section 8 of this 441 specification, Section 4 of [Part4], Section 3 of [Part5], and 442 Section 3 of [Part7]. The reason phrases listed here are only 443 recommendations -- they can be replaced by local equivalents without 444 affecting the protocol. 446 +-------------+------------------------------+----------------------+ 447 | Status-Code | Reason-Phrase | Defined in... | 448 +-------------+------------------------------+----------------------+ 449 | 100 | Continue | Section 8.1.1 | 450 | 101 | Switching Protocols | Section 8.1.2 | 451 | 200 | OK | Section 8.2.1 | 452 | 201 | Created | Section 8.2.2 | 453 | 202 | Accepted | Section 8.2.3 | 454 | 203 | Non-Authoritative | Section 8.2.4 | 455 | | Information | | 456 | 204 | No Content | Section 8.2.5 | 457 | 205 | Reset Content | Section 8.2.6 | 458 | 206 | Partial Content | Section 3.1 of | 459 | | | [Part5] | 460 | 300 | Multiple Choices | Section 8.3.1 | 461 | 301 | Moved Permanently | Section 8.3.2 | 462 | 302 | Found | Section 8.3.3 | 463 | 303 | See Other | Section 8.3.4 | 464 | 304 | Not Modified | Section 4.1 of | 465 | | | [Part4] | 466 | 305 | Use Proxy | Section 8.3.6 | 467 | 307 | Temporary Redirect | Section 8.3.8 | 468 | 400 | Bad Request | Section 8.4.1 | 469 | 401 | Unauthorized | Section 3.1 of | 470 | | | [Part7] | 471 | 402 | Payment Required | Section 8.4.3 | 472 | 403 | Forbidden | Section 8.4.4 | 473 | 404 | Not Found | Section 8.4.5 | 474 | 405 | Method Not Allowed | Section 8.4.6 | 475 | 406 | Not Acceptable | Section 8.4.7 | 476 | 407 | Proxy Authentication | Section 3.2 of | 477 | | Required | [Part7] | 478 | 408 | Request Time-out | Section 8.4.9 | 479 | 409 | Conflict | Section 8.4.10 | 480 | 410 | Gone | Section 8.4.11 | 481 | 411 | Length Required | Section 8.4.12 | 482 | 412 | Precondition Failed | Section 4.2 of | 483 | | | [Part4] | 484 | 413 | Request Entity Too Large | Section 8.4.14 | 485 | 414 | URI Too Long | Section 8.4.15 | 486 | 415 | Unsupported Media Type | Section 8.4.16 | 487 | 416 | Requested range not | Section 3.2 of | 488 | | satisfiable | [Part5] | 489 | 417 | Expectation Failed | Section 8.4.18 | 490 | 426 | Upgrade Required | Section 8.4.19 | 491 | 500 | Internal Server Error | Section 8.5.1 | 492 | 501 | Not Implemented | Section 8.5.2 | 493 | 502 | Bad Gateway | Section 8.5.3 | 494 | 503 | Service Unavailable | Section 8.5.4 | 495 | 504 | Gateway Time-out | Section 8.5.5 | 496 | 505 | HTTP Version not supported | Section 8.5.6 | 497 +-------------+------------------------------+----------------------+ 499 Note that this list is not exhaustive -- it does not include 500 extension status codes defined in other specifications. 502 4.2. Status Code Registry 504 The HTTP Status Code Registry defines the name space for the Status- 505 Code token in the Status-Line of an HTTP response. 507 Values to be added to this name space are subject to IETF review 508 ([RFC5226], Section 4.1). 510 The registry itself is maintained at 511 . 513 4.2.1. Considerations for New Status Codes 515 When it is necessary to express new semantics for a HTTP response 516 that aren't specific to a single application or media type, and 517 currently defined status codes are inadequate, a new status code can 518 be registered. 520 HTTP status codes are generic; that is, they are potentially 521 applicable to any resource, not just one particular media type, 522 "type" of resource, or application. As such, it is preferred that 523 new HTTP status codes be registered in a document that isn't specific 524 to a single application, so that this is clear. 526 Definitions of new HTTP status codes typically explain the request 527 conditions that produce a response containing the status code (e.g., 528 combinations of request headers and/or method(s)), along with any 529 interactions with response headers (e.g., those that are required, 530 those that modify the semantics of the response). 532 New HTTP status codes are required to fall under one of the 533 categories defined in Section 8. To allow existing parsers to 534 properly handle them, new status codes cannot disallow a response 535 body, although they can mandate a zero-length response body. They 536 can require the presence of one or more particular HTTP response 537 header(s). 539 Likewise, their definitions can specify that caches are allowed to 540 use heuristics to determine their freshness (see [Part6]; by default, 541 it is not allowed), and can define how to determine the resource 542 which they carry a representation for (see Section 6.1; by default, 543 it is anonymous). 545 5. Response Header Fields 547 The response header fields allow the server to pass additional 548 information about the response which cannot be placed in the Status- 549 Line. These header fields give information about the server and 550 about further access to the target resource (Section 4.3 of [Part1]). 552 +--------------------+------------------------+ 553 | Header Field Name | Defined in... | 554 +--------------------+------------------------+ 555 | Accept-Ranges | Section 5.1 of [Part5] | 556 | Age | Section 3.1 of [Part6] | 557 | Allow | Section 9.1 | 558 | ETag | Section 2.2 of [Part4] | 559 | Location | Section 9.4 | 560 | Proxy-Authenticate | Section 4.2 of [Part7] | 561 | Retry-After | Section 9.7 | 562 | Server | Section 9.8 | 563 | Vary | Section 3.5 of [Part6] | 564 | WWW-Authenticate | Section 4.4 of [Part7] | 565 +--------------------+------------------------+ 567 6. Representation 569 Request and Response messages MAY transfer a representation if not 570 otherwise restricted by the request method or response status code. 571 A representation consists of metadata (representation header fields) 572 and data (representation body). When a complete or partial 573 representation is enclosed in an HTTP message, it is referred to as 574 the payload of the message. HTTP representations are defined in 575 [Part3]. 577 A representation body is only present in a message when a message- 578 body is present, as described in Section 3.3 of [Part1]. The 579 representation body is obtained from the message-body by decoding any 580 Transfer-Encoding that might have been applied to ensure safe and 581 proper transfer of the message. 583 6.1. Identifying the Resource Associated with a Representation 585 It is sometimes necessary to determine an identifier for the resource 586 associated with a representation. 588 An HTTP request representation, when present, is always associated 589 with an anonymous (i.e., unidentified) resource. 591 In the common case, an HTTP response is a representation of the 592 target resource (see Section 4.3 of [Part1]). However, this is not 593 always the case. To determine the URI of the resource a response is 594 associated with, the following rules are used (with the first 595 applicable one being selected): 597 1. If the response status code is 200 or 203 and the request method 598 was GET, the response payload is a representation of the target 599 resource. 601 2. If the response status code is 204, 206, or 304 and the request 602 method was GET or HEAD, the response payload is a partial 603 representation of the target resource (see Section 2.8 of 604 [Part6]). 606 3. If the response has a Content-Location header field, and that URI 607 is the same as the effective request URI, the response payload is 608 a representation of the target resource. 610 4. If the response has a Content-Location header field, and that URI 611 is not the same as the effective request URI, then the response 612 asserts that its payload is a representation of the resource 613 identified by the Content-Location URI. However, such an 614 assertion cannot be trusted unless it can be verified by other 615 means (not defined by HTTP). 617 5. Otherwise, the response is a representation of an anonymous 618 (i.e., unidentified) resource. 620 [[TODO-req-uri: The comparison function is going to have to be 621 defined somewhere, because we already need to compare URIs for things 622 like cache invalidation.]] 624 7. Method Definitions 626 The set of common request methods for HTTP/1.1 is defined below. 627 Although this set can be expanded, additional methods cannot be 628 assumed to share the same semantics for separately extended clients 629 and servers. 631 7.1. Safe and Idempotent Methods 633 7.1.1. Safe Methods 635 Implementors need to be aware that the software represents the user 636 in their interactions over the Internet, and need to allow the user 637 to be aware of any actions they take which might have an unexpected 638 significance to themselves or others. 640 In particular, the convention has been established that the GET, 641 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the 642 significance of taking an action other than retrieval. These request 643 methods ought to be considered "safe". This allows user agents to 644 represent other methods, such as POST, PUT and DELETE, in a special 645 way, so that the user is made aware of the fact that a possibly 646 unsafe action is being requested. 648 Naturally, it is not possible to ensure that the server does not 649 generate side-effects as a result of performing a GET request; in 650 fact, some dynamic resources consider that a feature. The important 651 distinction here is that the user did not request the side-effects, 652 so therefore cannot be held accountable for them. 654 7.1.2. Idempotent Methods 656 Request methods can also have the property of "idempotence" in that, 657 aside from error or expiration issues, the intended effect of 658 multiple identical requests is the same as for a single request. 659 PUT, DELETE, and all safe request methods are idempotent. It is 660 important to note that idempotence refers only to changes requested 661 by the client: a server is free to change its state due to multiple 662 requests for the purpose of tracking those requests, versioning of 663 results, etc. 665 7.2. OPTIONS 667 The OPTIONS method requests information about the communication 668 options available on the request/response chain identified by the 669 effective request URI. This method allows a client to determine the 670 options and/or requirements associated with a resource, or the 671 capabilities of a server, without implying a resource action or 672 initiating a resource retrieval. 674 Responses to the OPTIONS method are not cacheable. 676 If the OPTIONS request includes a message-body (as indicated by the 677 presence of Content-Length or Transfer-Encoding), then the media type 678 MUST be indicated by a Content-Type field. Although this 679 specification does not define any use for such a body, future 680 extensions to HTTP might use the OPTIONS body to make more detailed 681 queries on the server. 683 If the request-target is an asterisk ("*"), the OPTIONS request is 684 intended to apply to the server in general rather than to a specific 685 resource. Since a server's communication options typically depend on 686 the resource, the "*" request is only useful as a "ping" or "no-op" 687 type of method; it does nothing beyond allowing the client to test 688 the capabilities of the server. For example, this can be used to 689 test a proxy for HTTP/1.1 compliance (or lack thereof). 691 If the request-target is not an asterisk, the OPTIONS request applies 692 only to the options that are available when communicating with that 693 resource. 695 A 200 response SHOULD include any header fields that indicate 696 optional features implemented by the server and applicable to that 697 resource (e.g., Allow), possibly including extensions not defined by 698 this specification. The response body, if any, SHOULD also include 699 information about the communication options. The format for such a 700 body is not defined by this specification, but might be defined by 701 future extensions to HTTP. Content negotiation MAY be used to select 702 the appropriate response format. If no response body is included, 703 the response MUST include a Content-Length field with a field-value 704 of "0". 706 The Max-Forwards header field MAY be used to target a specific proxy 707 in the request chain (see Section 9.5). If no Max-Forwards field is 708 present in the request, then the forwarded request MUST NOT include a 709 Max-Forwards field. 711 7.3. GET 713 The GET method requests transfer of a current representation of the 714 target resource. 716 If the target resource is a data-producing process, it is the 717 produced data which shall be returned as the representation in the 718 response and not the source text of the process, unless that text 719 happens to be the output of the process. 721 The semantics of the GET method change to a "conditional GET" if the 722 request message includes an If-Modified-Since, If-Unmodified-Since, 723 If-Match, If-None-Match, or If-Range header field. A conditional GET 724 requests that the representation be transferred only under the 725 circumstances described by the conditional header field(s). The 726 conditional GET request is intended to reduce unnecessary network 727 usage by allowing cached representations to be refreshed without 728 requiring multiple requests or transferring data already held by the 729 client. 731 The semantics of the GET method change to a "partial GET" if the 732 request message includes a Range header field. A partial GET 733 requests that only part of the representation be transferred, as 734 described in Section 5.4 of [Part5]. The partial GET request is 735 intended to reduce unnecessary network usage by allowing partially- 736 retrieved representations to be completed without transferring data 737 already held by the client. 739 Bodies on GET requests have no defined semantics. Note that sending 740 a body on a GET request might cause some existing implementations to 741 reject the request. 743 The response to a GET request is cacheable and MAY be used to satisfy 744 subsequent GET and HEAD requests (see [Part6]). 746 See Section 11.2 for security considerations when used for forms. 748 7.4. HEAD 750 The HEAD method is identical to GET except that the server MUST NOT 751 return a message-body in the response. The metadata contained in the 752 HTTP header fields in response to a HEAD request SHOULD be identical 753 to the information sent in response to a GET request. This method 754 can be used for obtaining metadata about the representation implied 755 by the request without transferring the representation body. This 756 method is often used for testing hypertext links for validity, 757 accessibility, and recent modification. 759 The response to a HEAD request is cacheable and MAY be used to 760 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used 761 to update a previously cached representation from that resource; if 762 the new field values indicate that the cached representation differs 763 from the current representation (as would be indicated by a change in 764 Content-Length, Content-MD5, ETag or Last-Modified), then the cache 765 MUST treat the cache entry as stale. 767 Bodies on HEAD requests have no defined semantics. Note that sending 768 a body on a HEAD request might cause some existing implementations to 769 reject the request. 771 7.5. POST 773 The POST method requests that the origin server accept the 774 representation enclosed in the request as data to be processed by the 775 target resource. POST is designed to allow a uniform method to cover 776 the following functions: 778 o Annotation of existing resources; 780 o Posting a message to a bulletin board, newsgroup, mailing list, or 781 similar group of articles; 783 o Providing a block of data, such as the result of submitting a 784 form, to a data-handling process; 786 o Extending a database through an append operation. 788 The actual function performed by the POST method is determined by the 789 server and is usually dependent on the effective request URI. 791 The action performed by the POST method might not result in a 792 resource that can be identified by a URI. In this case, either 200 793 (OK) or 204 (No Content) is the appropriate response status code, 794 depending on whether or not the response includes a representation 795 that describes the result. 797 If a resource has been created on the origin server, the response 798 SHOULD be 201 (Created) and contain a representation which describes 799 the status of the request and refers to the new resource, and a 800 Location header field (see Section 9.4). 802 Responses to POST requests are only cacheable when they include 803 explicit freshness information (see Section 2.3.1 of [Part6]). A 804 cached POST response with a Content-Location header field (see 805 Section 6.7 of [Part3]) whose value is the effective Request URI MAY 806 be used to satisfy subsequent GET and HEAD requests. 808 Note that POST caching is not widely implemented. However, the 303 809 (See Other) response can be used to direct the user agent to retrieve 810 a cacheable resource. 812 7.6. PUT 814 The PUT method requests that the state of the target resource be 815 created or replaced with the state defined by the representation 816 enclosed in the request message payload. A successful PUT of a given 817 representation would suggest that a subsequent GET on that same 818 target resource will result in an equivalent representation being 819 returned in a 200 (OK) response. However, there is no guarantee that 820 such a state change will be observable, since the target resource 821 might be acted upon by other user agents in parallel, or might be 822 subject to dynamic processing by the origin server, before any 823 subsequent GET is received. A successful response only implies that 824 the user agent's intent was achieved at the time of its processing by 825 the origin server. 827 If the target resource does not have a current representation and the 828 PUT successfully creates one, then the origin server MUST inform the 829 user agent by sending a 201 (Created) response. If the target 830 resource does have a current representation and that representation 831 is successfully modified in accordance with the state of the enclosed 832 representation, then either a 200 (OK) or 204 (No Content) response 833 SHOULD be sent to indicate successful completion of the request. 835 Unrecognized header fields SHOULD be ignored (i.e., not saved as part 836 of the resource state). 838 An origin server SHOULD verify that the PUT representation is 839 consistent with any constraints which the server has for the target 840 resource that cannot or will not be changed by the PUT. This is 841 particularly important when the origin server uses internal 842 configuration information related to the URI in order to set the 843 values for representation metadata on GET responses. When a PUT 844 representation is inconsistent with the target resource, the origin 845 server SHOULD either make them consistent, by transforming the 846 representation or changing the resource configuration, or respond 847 with an appropriate error message containing sufficient information 848 to explain why the representation is unsuitable. The 409 (Conflict) 849 or 415 (Unsupported Media Type) status codes are suggested, with the 850 latter being specific to constraints on Content-Type values. 852 For example, if the target resource is configured to always have a 853 Content-Type of "text/html" and the representation being PUT has a 854 Content-Type of "image/jpeg", then the origin server SHOULD do one 855 of: (a) reconfigure the target resource to reflect the new media 856 type; (b) transform the PUT representation to a format consistent 857 with that of the resource before saving it as the new resource state; 858 or, (c) reject the request with a 415 response indicating that the 859 target resource is limited to "text/html", perhaps including a link 860 to a different resource that would be a suitable target for the new 861 representation. 863 HTTP does not define exactly how a PUT method affects the state of an 864 origin server beyond what can be expressed by the intent of the user 865 agent request and the semantics of the origin server response. It 866 does not define what a resource might be, in any sense of that word, 867 beyond the interface provided via HTTP. It does not define how 868 resource state is "stored", nor how such storage might change as a 869 result of a change in resource state, nor how the origin server 870 translates resource state into representations. Generally speaking, 871 all implementation details behind the resource interface are 872 intentionally hidden by the server. 874 The fundamental difference between the POST and PUT methods is 875 highlighted by the different intent for the target resource. The 876 target resource in a POST request is intended to handle the enclosed 877 representation as a data-accepting process, such as for a gateway to 878 some other protocol or a document that accepts annotations. In 879 contrast, the target resource in a PUT request is intended to take 880 the enclosed representation as a new or replacement value. Hence, 881 the intent of PUT is idempotent and visible to intermediaries, even 882 though the exact effect is only known by the origin server. 884 Proper interpretation of a PUT request presumes that the user agent 885 knows what target resource is desired. A service that is intended to 886 select a proper URI on behalf of the client, after receiving a state- 887 changing request, SHOULD be implemented using the POST method rather 888 than PUT. If the origin server will not make the requested PUT state 889 change to the target resource and instead wishes to have it applied 890 to a different resource, such as when the resource has been moved to 891 a different URI, then the origin server MUST send a 301 (Moved 892 Permanently) response; the user agent MAY then make its own decision 893 regarding whether or not to redirect the request. 895 A PUT request applied to the target resource MAY have side-effects on 896 other resources. For example, an article might have a URI for 897 identifying "the current version" (a resource) which is separate from 898 the URIs identifying each particular version (different resources 899 that at one point shared the same state as the current version 900 resource). A successful PUT request on "the current version" URI 901 might therefore create a new version resource in addition to changing 902 the state of the target resource, and might also cause links to be 903 added between the related resources. 905 An origin server SHOULD reject any PUT request that contains a 906 Content-Range header field, since it might be misinterpreted as 907 partial content (or might be partial content that is being mistakenly 908 PUT as a full representation). Partial content updates are possible 909 by targeting a separately identified resource with state that 910 overlaps a portion of the larger resource, or by using a different 911 method that has been specifically defined for partial updates (for 912 example, the PATCH method defined in [RFC5789]). 914 Responses to the PUT method are not cacheable. If a PUT request 915 passes through a cache that has one or more stored responses for the 916 effective request URI, those stored responses will be invalidated 917 (see Section 2.5 of [Part6]). 919 7.7. DELETE 921 The DELETE method requests that the origin server delete the target 922 resource. This method MAY be overridden by human intervention (or 923 other means) on the origin server. The client cannot be guaranteed 924 that the operation has been carried out, even if the status code 925 returned from the origin server indicates that the action has been 926 completed successfully. However, the server SHOULD NOT indicate 927 success unless, at the time the response is given, it intends to 928 delete the resource or move it to an inaccessible location. 930 A successful response SHOULD be 200 (OK) if the response includes an 931 representation describing the status, 202 (Accepted) if the action 932 has not yet been enacted, or 204 (No Content) if the action has been 933 enacted but the response does not include a representation. 935 Bodies on DELETE requests have no defined semantics. Note that 936 sending a body on a DELETE request might cause some existing 937 implementations to reject the request. 939 Responses to the DELETE method are not cacheable. If a DELETE 940 request passes through a cache that has one or more stored responses 941 for the effective request URI, those stored responses will be 942 invalidated (see Section 2.5 of [Part6]). 944 7.8. TRACE 946 The TRACE method requests a remote, application-layer loop-back of 947 the request message. The final recipient of the request SHOULD 948 reflect the message received back to the client as the message-body 949 of a 200 (OK) response. The final recipient is either the origin 950 server or the first proxy to receive a Max-Forwards value of zero (0) 951 in the request (see Section 9.5). A TRACE request MUST NOT include a 952 message-body. 954 TRACE allows the client to see what is being received at the other 955 end of the request chain and use that data for testing or diagnostic 956 information. The value of the Via header field (Section 9.9 of 957 [Part1]) is of particular interest, since it acts as a trace of the 958 request chain. Use of the Max-Forwards header field allows the 959 client to limit the length of the request chain, which is useful for 960 testing a chain of proxies forwarding messages in an infinite loop. 962 If the request is valid, the response SHOULD have a Content-Type of 963 "message/http" (see Section 10.3.1 of [Part1]) and contain a message- 964 body that encloses a copy of the entire request message. Responses 965 to the TRACE method are not cacheable. 967 7.9. CONNECT 969 The CONNECT method requests that the proxy establish a tunnel to the 970 request-target and then restrict its behavior to blind forwarding of 971 packets until the connection is closed. 973 When using CONNECT, the request-target MUST use the authority form 974 (Section 4.1.2 of [Part1]); i.e., the request-target consists of only 975 the host name and port number of the tunnel destination, separated by 976 a colon. For example, 978 CONNECT server.example.com:80 HTTP/1.1 979 Host: server.example.com:80 981 Other HTTP mechanisms can be used normally with the CONNECT method -- 982 except end-to-end protocol Upgrade requests, since the tunnel must be 983 established first. 985 For example, proxy authentication might be used to establish the 986 authority to create a tunnel: 988 CONNECT server.example.com:80 HTTP/1.1 989 Host: server.example.com:80 990 Proxy-Authorization: basic aGVsbG86d29ybGQ= 992 Bodies on CONNECT requests have no defined semantics. Note that 993 sending a body on a CONNECT request might cause some existing 994 implementations to reject the request. 996 Like any other pipelined HTTP/1.1 request, data to be tunnel may be 997 sent immediately after the blank line. The usual caveats also apply: 998 data may be discarded if the eventual response is negative, and the 999 connection may be reset with no response if more than one TCP segment 1000 is outstanding. 1002 7.9.1. Establishing a Tunnel with CONNECT 1004 Any successful (2xx) response to a CONNECT request indicates that the 1005 proxy has established a connection to the requested host and port, 1006 and has switched to tunneling the current connection to that server 1007 connection. 1009 It may be the case that the proxy itself can only reach the requested 1010 origin server through another proxy. In this case, the first proxy 1011 SHOULD make a CONNECT request of that next proxy, requesting a tunnel 1012 to the authority. A proxy MUST NOT respond with any 2xx status code 1013 unless it has either a direct or tunnel connection established to the 1014 authority. 1016 An origin server which receives a CONNECT request for itself MAY 1017 respond with a 2xx status code to indicate that a connection is 1018 established. 1020 If at any point either one of the peers gets disconnected, any 1021 outstanding data that came from that peer will be passed to the other 1022 one, and after that also the other connection will be terminated by 1023 the proxy. If there is outstanding data to that peer undelivered, 1024 that data will be discarded. 1026 8. Status Code Definitions 1028 Each Status-Code is described below, including any metadata required 1029 in the response. 1031 8.1. Informational 1xx 1033 This class of status code indicates a provisional response, 1034 consisting only of the Status-Line and optional header fields, and is 1035 terminated by an empty line. There are no required header fields for 1036 this class of status code. Since HTTP/1.0 did not define any 1xx 1037 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 1038 client except under experimental conditions. 1040 A client MUST be prepared to accept one or more 1xx status responses 1041 prior to a regular response, even if the client does not expect a 100 1042 (Continue) status message. Unexpected 1xx status responses MAY be 1043 ignored by a user agent. 1045 Proxies MUST forward 1xx responses, unless the connection between the 1046 proxy and its client has been closed, or unless the proxy itself 1047 requested the generation of the 1xx response. (For example, if a 1048 proxy adds a "Expect: 100-continue" field when it forwards a request, 1049 then it need not forward the corresponding 100 (Continue) 1050 response(s).) 1052 8.1.1. 100 Continue 1054 The client SHOULD continue with its request. This interim response 1055 is used to inform the client that the initial part of the request has 1056 been received and has not yet been rejected by the server. The 1057 client SHOULD continue by sending the remainder of the request or, if 1058 the request has already been completed, ignore this response. The 1059 server MUST send a final response after the request has been 1060 completed. See Section 7.2.3 of [Part1] for detailed discussion of 1061 the use and handling of this status code. 1063 8.1.2. 101 Switching Protocols 1065 The server understands and is willing to comply with the client's 1066 request, via the Upgrade message header field (Section 9.8 of 1067 [Part1]), for a change in the application protocol being used on this 1068 connection. The server will switch protocols to those defined by the 1069 response's Upgrade header field immediately after the empty line 1070 which terminates the 101 response. 1072 The protocol SHOULD be switched only when it is advantageous to do 1073 so. For example, switching to a newer version of HTTP is 1074 advantageous over older versions, and switching to a real-time, 1075 synchronous protocol might be advantageous when delivering resources 1076 that use such features. 1078 8.2. Successful 2xx 1080 This class of status code indicates that the client's request was 1081 successfully received, understood, and accepted. 1083 8.2.1. 200 OK 1085 The request has succeeded. The payload returned with the response is 1086 dependent on the method used in the request, for example: 1088 GET a representation of the target resource is sent in the response; 1090 HEAD the same representation as GET, except without the message- 1091 body; 1093 POST a representation describing or containing the result of the 1094 action; 1096 TRACE a representation containing the request message as received by 1097 the end server. 1099 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1100 determine freshness for 200 responses. 1102 8.2.2. 201 Created 1104 The request has been fulfilled and has resulted in a new resource 1105 being created. The newly created resource can be referenced by the 1106 URI(s) returned in the payload of the response, with the most 1107 specific URI for the resource given by a Location header field. The 1108 response SHOULD include a payload containing a list of resource 1109 characteristics and location(s) from which the user or user agent can 1110 choose the one most appropriate. The payload format is specified by 1111 the media type given in the Content-Type header field. The origin 1112 server MUST create the resource before returning the 201 status code. 1113 If the action cannot be carried out immediately, the server SHOULD 1114 respond with 202 (Accepted) response instead. 1116 A 201 response MAY contain an ETag response header field indicating 1117 the current value of the entity-tag for the representation of the 1118 resource just created (see Section 2.2 of [Part4]). 1120 8.2.3. 202 Accepted 1122 The request has been accepted for processing, but the processing has 1123 not been completed. The request might or might not eventually be 1124 acted upon, as it might be disallowed when processing actually takes 1125 place. There is no facility for re-sending a status code from an 1126 asynchronous operation such as this. 1128 The 202 response is intentionally non-committal. Its purpose is to 1129 allow a server to accept a request for some other process (perhaps a 1130 batch-oriented process that is only run once per day) without 1131 requiring that the user agent's connection to the server persist 1132 until the process is completed. The representation returned with 1133 this response SHOULD include an indication of the request's current 1134 status and either a pointer to a status monitor or some estimate of 1135 when the user can expect the request to be fulfilled. 1137 8.2.4. 203 Non-Authoritative Information 1139 The returned metadata in the header fields is not the definitive set 1140 as available from the origin server, but is gathered from a local or 1141 a third-party copy. The set presented MAY be a subset or superset of 1142 the original version. For example, including local annotation 1143 information about the resource might result in a superset of the 1144 metadata known by the origin server. Use of this response code is 1145 not required and is only appropriate when the response would 1146 otherwise be 200 (OK). 1148 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1149 determine freshness for 203 responses. 1151 8.2.5. 204 No Content 1153 The 204 (No Content) status code indicates that the server has 1154 successfully fulfilled the request and that there is no additional 1155 content to return in the response payload body. Metadata in the 1156 response header fields refer to the target resource and its current 1157 representation after the requested action. 1159 For example, if a 204 status code is received in response to a PUT 1160 request and the response contains an ETag header field, then the PUT 1161 was successful and the ETag field-value contains the entity-tag for 1162 the new representation of that target resource. 1164 The 204 response allows a server to indicate that the action has been 1165 successfully applied to the target resource while implying that the 1166 user agent SHOULD NOT traverse away from its current "document view" 1167 (if any). The server assumes that the user agent will provide some 1168 indication of the success to its user, in accord with its own 1169 interface, and apply any new or updated metadata in the response to 1170 the active representation. For example, a 204 status code is 1171 commonly used with document editing interfaces corresponding to a 1172 "save" action, such that the document being saved remains available 1173 to the user for editing. It is also frequently used with interfaces 1174 that expect automated data transfers to be prevalent, such as within 1175 distributed version control systems. 1177 The 204 response MUST NOT include a message-body, and thus is always 1178 terminated by the first empty line after the header fields. 1180 8.2.6. 205 Reset Content 1182 The server has fulfilled the request and the user agent SHOULD reset 1183 the document view which caused the request to be sent. This response 1184 is primarily intended to allow input for actions to take place via 1185 user input, followed by a clearing of the form in which the input is 1186 given so that the user can easily initiate another input action. 1188 The message-body included with the response MUST be empty. Note that 1189 receivers still need to parse the response according to the algorithm 1190 defined in Section 3.3 of [Part1]. 1192 8.2.7. 206 Partial Content 1194 The server has fulfilled the partial GET request for the resource and 1195 the enclosed payload is a partial representation as defined in 1196 Section 3.1 of [Part5]. 1198 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1199 determine freshness for 206 responses. 1201 8.3. Redirection 3xx 1203 This class of status code indicates that further action needs to be 1204 taken by the user agent in order to fulfill the request. The action 1205 required MAY be carried out by the user agent without interaction 1206 with the user if and only if the method used in the second request is 1207 known to be "safe", as defined in Section 7.1.1. A client SHOULD 1208 detect infinite redirection loops, since such loops generate network 1209 traffic for each redirection. 1211 Note: An earlier version of this specification recommended a 1212 maximum of five redirections ([RFC2068], Section 10.3). Content 1213 developers need to be aware that some clients might implement such 1214 a fixed limitation. 1216 8.3.1. 300 Multiple Choices 1218 The target resource has more than one representation, each with its 1219 own specific location, and agent-driven negotiation information 1220 (Section 5 of [Part3]) is being provided so that the user (or user 1221 agent) can select a preferred representation by redirecting its 1222 request to that location. 1224 Unless it was a HEAD request, the response SHOULD include a 1225 representation containing a list of representation metadata and 1226 location(s) from which the user or user agent can choose the one most 1227 appropriate. The data format is specified by the media type given in 1228 the Content-Type header field. Depending upon the format and the 1229 capabilities of the user agent, selection of the most appropriate 1230 choice MAY be performed automatically. However, this specification 1231 does not define any standard for such automatic selection. 1233 If the server has a preferred choice of representation, it SHOULD 1234 include the specific URI for that representation in the Location 1235 field; user agents MAY use the Location field value for automatic 1236 redirection. 1238 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1239 determine freshness for 300 responses. 1241 8.3.2. 301 Moved Permanently 1243 The target resource has been assigned a new permanent URI and any 1244 future references to this resource SHOULD use one of the returned 1245 URIs. Clients with link editing capabilities ought to automatically 1246 re-link references to the effective request URI to one or more of the 1247 new references returned by the server, where possible. 1249 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1250 determine freshness for 301 responses. 1252 The new permanent URI SHOULD be given by the Location field in the 1253 response. Unless the request method was HEAD, the representation of 1254 the response SHOULD contain a short hypertext note with a hyperlink 1255 to the new URI(s). 1257 If the 301 status code is received in response to a request method 1258 that is known to be "safe", as defined in Section 7.1.1, then the 1259 request MAY be automatically redirected by the user agent without 1260 confirmation. Otherwise, the user agent MUST NOT automatically 1261 redirect the request unless it can be confirmed by the user, since 1262 this might change the conditions under which the request was issued. 1264 Note: When automatically redirecting a POST request after 1265 receiving a 301 status code, some existing HTTP/1.0 user agents 1266 will erroneously change it into a GET request. 1268 8.3.3. 302 Found 1270 The target resource resides temporarily under a different URI. Since 1271 the redirection might be altered on occasion, the client SHOULD 1272 continue to use the effective request URI for future requests. 1274 The temporary URI SHOULD be given by the Location field in the 1275 response. Unless the request method was HEAD, the representation of 1276 the response SHOULD contain a short hypertext note with a hyperlink 1277 to the new URI(s). 1279 If the 302 status code is received in response to a request method 1280 that is known to be "safe", as defined in Section 7.1.1, then the 1281 request MAY be automatically redirected by the user agent without 1282 confirmation. Otherwise, the user agent MUST NOT automatically 1283 redirect the request unless it can be confirmed by the user, since 1284 this might change the conditions under which the request was issued. 1286 Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of 1287 HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is 1288 not allowed to change the method on the redirected request. 1289 However, most existing user agent implementations treat 302 as if 1290 it were a 303 response, performing a GET on the Location field- 1291 value regardless of the original request method. Therefore, a 1292 previous version of this specification ([RFC2616], Section 10.3.3) 1293 has added the status codes 303 and 307 for servers that wish to 1294 make unambiguously clear which kind of reaction is expected of the 1295 client. 1297 8.3.4. 303 See Other 1299 The server directs the user agent to a different resource, indicated 1300 by a URI in the Location header field, that provides an indirect 1301 response to the original request. The user agent MAY perform a GET 1302 request on the URI in the Location field in order to obtain a 1303 representation corresponding to the response, be redirected again, or 1304 end with an error status. The Location URI is not a substitute 1305 reference for the effective request URI. 1307 The 303 status code is generally applicable to any HTTP method. It 1308 is primarily used to allow the output of a POST action to redirect 1309 the user agent to a selected resource, since doing so provides the 1310 information corresponding to the POST response in a form that can be 1311 separately identified, bookmarked, and cached independent of the 1312 original request. 1314 A 303 response to a GET request indicates that the requested resource 1315 does not have a representation of its own that can be transferred by 1316 the server over HTTP. The Location URI indicates a resource that is 1317 descriptive of the target resource, such that the follow-on 1318 representation might be useful to recipients without implying that it 1319 adequately represents the target resource. Note that answers to the 1320 questions of what can be represented, what representations are 1321 adequate, and what might be a useful description are outside the 1322 scope of HTTP and thus entirely determined by the URI owner(s). 1324 Except for responses to a HEAD request, the representation of a 303 1325 response SHOULD contain a short hypertext note with a hyperlink to 1326 the Location URI. 1328 8.3.5. 304 Not Modified 1330 The response to the request has not been modified since the 1331 conditions indicated by the client's conditional GET request, as 1332 defined in Section 4.1 of [Part4]. 1334 8.3.6. 305 Use Proxy 1336 The 305 status code was defined in a previous version of this 1337 specification (see Appendix A), and is now deprecated. 1339 8.3.7. 306 (Unused) 1341 The 306 status code was used in a previous version of the 1342 specification, is no longer used, and the code is reserved. 1344 8.3.8. 307 Temporary Redirect 1346 The target resource resides temporarily under a different URI. Since 1347 the redirection can change over time, the client SHOULD continue to 1348 use the effective request URI for future requests. 1350 The temporary URI SHOULD be given by the Location field in the 1351 response. Unless the request method was HEAD, the representation of 1352 the response SHOULD contain a short hypertext note with a hyperlink 1353 to the new URI(s), since many pre-HTTP/1.1 user agents do not 1354 understand the 307 status code. Therefore, the note SHOULD contain 1355 the information necessary for a user to repeat the original request 1356 on the new URI. 1358 If the 307 status code is received in response to a request method 1359 that is known to be "safe", as defined in Section 7.1.1, then the 1360 request MAY be automatically redirected by the user agent without 1361 confirmation. Otherwise, the user agent MUST NOT automatically 1362 redirect the request unless it can be confirmed by the user, since 1363 this might change the conditions under which the request was issued. 1365 8.4. Client Error 4xx 1367 The 4xx class of status code is intended for cases in which the 1368 client seems to have erred. Except when responding to a HEAD 1369 request, the server SHOULD include a representation containing an 1370 explanation of the error situation, and whether it is a temporary or 1371 permanent condition. These status codes are applicable to any 1372 request method. User agents SHOULD display any included 1373 representation to the user. 1375 If the client is sending data, a server implementation using TCP 1376 SHOULD be careful to ensure that the client acknowledges receipt of 1377 the packet(s) containing the response, before the server closes the 1378 input connection. If the client continues sending data to the server 1379 after the close, the server's TCP stack will send a reset packet to 1380 the client, which might erase the client's unacknowledged input 1381 buffers before they can be read and interpreted by the HTTP 1382 application. 1384 8.4.1. 400 Bad Request 1386 The request could not be understood by the server due to malformed 1387 syntax. The client SHOULD NOT repeat the request without 1388 modifications. 1390 8.4.2. 401 Unauthorized 1392 The request requires user authentication (see Section 3.1 of 1393 [Part7]). 1395 8.4.3. 402 Payment Required 1397 This code is reserved for future use. 1399 8.4.4. 403 Forbidden 1401 The server understood the request, but is refusing to fulfill it. 1402 Authorization will not help and the request SHOULD NOT be repeated. 1404 If the request method was not HEAD and the server wishes to make 1405 public why the request has not been fulfilled, it SHOULD describe the 1406 reason for the refusal in the representation. If the server does not 1407 wish to make this information available to the client, the status 1408 code 404 (Not Found) can be used instead. 1410 8.4.5. 404 Not Found 1412 The server has not found anything matching the effective request URI. 1413 No indication is given of whether the condition is temporary or 1414 permanent. The 410 (Gone) status code SHOULD be used if the server 1415 knows, through some internally configurable mechanism, that an old 1416 resource is permanently unavailable and has no forwarding address. 1417 This status code is commonly used when the server does not wish to 1418 reveal exactly why the request has been refused, or when no other 1419 response is applicable. 1421 8.4.6. 405 Method Not Allowed 1423 The method specified in the Request-Line is not allowed for the 1424 target resource. The response MUST include an Allow header field 1425 containing a list of valid methods for the requested resource. 1427 8.4.7. 406 Not Acceptable 1429 The resource identified by the request is only capable of generating 1430 response representations which have content characteristics not 1431 acceptable according to the accept header fields sent in the request. 1433 Unless it was a HEAD request, the response SHOULD include a 1434 representation containing a list of available representation 1435 characteristics and location(s) from which the user or user agent can 1436 choose the one most appropriate. The data format is specified by the 1437 media type given in the Content-Type header field. Depending upon 1438 the format and the capabilities of the user agent, selection of the 1439 most appropriate choice MAY be performed automatically. However, 1440 this specification does not define any standard for such automatic 1441 selection. 1443 Note: HTTP/1.1 servers are allowed to return responses which are 1444 not acceptable according to the accept header fields sent in the 1445 request. In some cases, this might even be preferable to sending 1446 a 406 response. User agents are encouraged to inspect the header 1447 fields of an incoming response to determine if it is acceptable. 1449 If the response could be unacceptable, a user agent SHOULD 1450 temporarily stop receipt of more data and query the user for a 1451 decision on further actions. 1453 8.4.8. 407 Proxy Authentication Required 1455 This code is similar to 401 (Unauthorized), but indicates that the 1456 client must first authenticate itself with the proxy (see Section 3.2 1457 of [Part7]). 1459 8.4.9. 408 Request Timeout 1461 The client did not produce a request within the time that the server 1462 was prepared to wait. The client MAY repeat the request without 1463 modifications at any later time. 1465 8.4.10. 409 Conflict 1467 The request could not be completed due to a conflict with the current 1468 state of the resource. This code is only allowed in situations where 1469 it is expected that the user might be able to resolve the conflict 1470 and resubmit the request. The response body SHOULD include enough 1471 information for the user to recognize the source of the conflict. 1472 Ideally, the response representation would include enough information 1473 for the user or user agent to fix the problem; however, that might 1474 not be possible and is not required. 1476 Conflicts are most likely to occur in response to a PUT request. For 1477 example, if versioning were being used and the representation being 1478 PUT included changes to a resource which conflict with those made by 1479 an earlier (third-party) request, the server might use the 409 1480 response to indicate that it can't complete the request. In this 1481 case, the response representation would likely contain a list of the 1482 differences between the two versions in a format defined by the 1483 response Content-Type. 1485 8.4.11. 410 Gone 1487 The target resource is no longer available at the server and no 1488 forwarding address is known. This condition is expected to be 1489 considered permanent. Clients with link editing capabilities SHOULD 1490 delete references to the effective request URI after user approval. 1491 If the server does not know, or has no facility to determine, whether 1492 or not the condition is permanent, the status code 404 (Not Found) 1493 SHOULD be used instead. 1495 The 410 response is primarily intended to assist the task of web 1496 maintenance by notifying the recipient that the resource is 1497 intentionally unavailable and that the server owners desire that 1498 remote links to that resource be removed. Such an event is common 1499 for limited-time, promotional services and for resources belonging to 1500 individuals no longer working at the server's site. It is not 1501 necessary to mark all permanently unavailable resources as "gone" or 1502 to keep the mark for any length of time -- that is left to the 1503 discretion of the server owner. 1505 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1506 determine freshness for 410 responses. 1508 8.4.12. 411 Length Required 1510 The server refuses to accept the request without a defined Content- 1511 Length. The client MAY repeat the request if it adds a valid 1512 Content-Length header field containing the length of the message-body 1513 in the request message. 1515 8.4.13. 412 Precondition Failed 1517 The precondition given in one or more of the header fields evaluated 1518 to false when it was tested on the server, as defined in Section 4.2 1519 of [Part4]. 1521 8.4.14. 413 Request Entity Too Large 1523 The server is refusing to process a request because the request 1524 representation is larger than the server is willing or able to 1525 process. The server MAY close the connection to prevent the client 1526 from continuing the request. 1528 If the condition is temporary, the server SHOULD include a Retry- 1529 After header field to indicate that it is temporary and after what 1530 time the client MAY try again. 1532 8.4.15. 414 URI Too Long 1534 The server is refusing to service the request because the effective 1535 request URI is longer than the server is willing to interpret. This 1536 rare condition is only likely to occur when a client has improperly 1537 converted a POST request to a GET request with long query 1538 information, when the client has descended into a URI "black hole" of 1539 redirection (e.g., a redirected URI prefix that points to a suffix of 1540 itself), or when the server is under attack by a client attempting to 1541 exploit security holes present in some servers using fixed-length 1542 buffers for reading or manipulating the effective request URI. 1544 8.4.16. 415 Unsupported Media Type 1546 The server is refusing to service the request because the request 1547 payload is in a format not supported by this request method on the 1548 target resource. 1550 8.4.17. 416 Requested Range Not Satisfiable 1552 The request included a Range header field (Section 5.4 of [Part5]) 1553 and none of the range-specifier values in this field overlap the 1554 current extent of the selected resource. See Section 3.2 of [Part5]. 1556 8.4.18. 417 Expectation Failed 1558 The expectation given in an Expect header field (see Section 9.2) 1559 could not be met by this server, or, if the server is a proxy, the 1560 server has unambiguous evidence that the request could not be met by 1561 the next-hop server. 1563 8.4.19. 426 Upgrade Required 1565 The request can not be completed without a prior protocol upgrade. 1566 This response MUST include an Upgrade header field (Section 9.8 of 1567 [Part1]) specifying the required protocols. 1569 Example: 1571 HTTP/1.1 426 Upgrade Required 1572 Upgrade: HTTP/2.0 1573 Connection: Upgrade 1575 The server SHOULD include a message body in the 426 response which 1576 indicates in human readable form the reason for the error and 1577 describes any alternative courses which may be available to the user. 1579 8.5. Server Error 5xx 1581 Response status codes beginning with the digit "5" indicate cases in 1582 which the server is aware that it has erred or is incapable of 1583 performing the request. Except when responding to a HEAD request, 1584 the server SHOULD include a representation containing an explanation 1585 of the error situation, and whether it is a temporary or permanent 1586 condition. User agents SHOULD display any included representation to 1587 the user. These response codes are applicable to any request method. 1589 8.5.1. 500 Internal Server Error 1591 The server encountered an unexpected condition which prevented it 1592 from fulfilling the request. 1594 8.5.2. 501 Not Implemented 1596 The server does not support the functionality required to fulfill the 1597 request. This is the appropriate response when the server does not 1598 recognize the request method and is not capable of supporting it for 1599 any resource. 1601 8.5.3. 502 Bad Gateway 1603 The server, while acting as a gateway or proxy, received an invalid 1604 response from the upstream server it accessed in attempting to 1605 fulfill the request. 1607 8.5.4. 503 Service Unavailable 1609 The server is currently unable to handle the request due to a 1610 temporary overloading or maintenance of the server. The implication 1611 is that this is a temporary condition which will be alleviated after 1612 some delay. If known, the length of the delay MAY be indicated in a 1613 Retry-After header field. If no Retry-After is given, the client 1614 SHOULD handle the response as it would for a 500 response. 1616 Note: The existence of the 503 status code does not imply that a 1617 server must use it when becoming overloaded. Some servers might 1618 wish to simply refuse the connection. 1620 8.5.5. 504 Gateway Timeout 1622 The server, while acting as a gateway or proxy, did not receive a 1623 timely response from the upstream server specified by the URI (e.g., 1624 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 1625 to access in attempting to complete the request. 1627 Note to implementors: some deployed proxies are known to return 1628 400 or 500 when DNS lookups time out. 1630 8.5.6. 505 HTTP Version Not Supported 1632 The server does not support, or refuses to support, the protocol 1633 version that was used in the request message. The server is 1634 indicating that it is unable or unwilling to complete the request 1635 using the same major version as the client, as described in Section 1636 2.5 of [Part1], other than with this error message. The response 1637 SHOULD contain a representation describing why that version is not 1638 supported and what other protocols are supported by that server. 1640 9. Header Field Definitions 1642 This section defines the syntax and semantics of HTTP/1.1 header 1643 fields related to request and response semantics. 1645 9.1. Allow 1647 The "Allow" header field lists the set of methods advertised as 1648 supported by the target resource. The purpose of this field is 1649 strictly to inform the recipient of valid request methods associated 1650 with the resource. 1652 Allow = #Method 1654 Example of use: 1656 Allow: GET, HEAD, PUT 1658 The actual set of allowed methods is defined by the origin server at 1659 the time of each request. 1661 A proxy MUST NOT modify the Allow header field -- it does not need to 1662 understand all the methods specified in order to handle them 1663 according to the generic message handling rules. 1665 9.2. Expect 1667 The "Expect" header field is used to indicate that particular server 1668 behaviors are required by the client. 1670 Expect = 1#expectation 1672 expectation = "100-continue" / expectation-extension 1673 expectation-extension = token [ "=" ( token / quoted-string ) 1674 *expect-params ] 1675 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1677 A server that does not understand or is unable to comply with any of 1678 the expectation values in the Expect field of a request MUST respond 1679 with appropriate error status code. The server MUST respond with a 1680 417 (Expectation Failed) status code if any of the expectations 1681 cannot be met or, if there are other problems with the request, some 1682 other 4xx status code. 1684 This header field is defined with extensible syntax to allow for 1685 future extensions. If a server receives a request containing an 1686 Expect field that includes an expectation-extension that it does not 1687 support, it MUST respond with a 417 (Expectation Failed) status code. 1689 Comparison of expectation values is case-insensitive for unquoted 1690 tokens (including the 100-continue token), and is case-sensitive for 1691 quoted-string expectation-extensions. 1693 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1694 return a 417 (Expectation Failed) status code if it receives a 1695 request with an expectation that it cannot meet. However, the Expect 1696 header field itself is end-to-end; it MUST be forwarded if the 1697 request is forwarded. 1699 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1700 Expect header field. 1702 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status 1703 code. 1705 9.3. From 1707 The "From" header field, if given, SHOULD contain an Internet e-mail 1708 address for the human user who controls the requesting user agent. 1709 The address SHOULD be machine-usable, as defined by "mailbox" in 1710 Section 3.4 of [RFC5322]: 1712 From = mailbox 1714 mailbox = 1716 An example is: 1718 From: webmaster@example.org 1720 This header field MAY be used for logging purposes and as a means for 1721 identifying the source of invalid or unwanted requests. It SHOULD 1722 NOT be used as an insecure form of access protection. The 1723 interpretation of this field is that the request is being performed 1724 on behalf of the person given, who accepts responsibility for the 1725 method performed. In particular, robot agents SHOULD include this 1726 header field so that the person responsible for running the robot can 1727 be contacted if problems occur on the receiving end. 1729 The Internet e-mail address in this field MAY be separate from the 1730 Internet host which issued the request. For example, when a request 1731 is passed through a proxy the original issuer's address SHOULD be 1732 used. 1734 The client SHOULD NOT send the From header field without the user's 1735 approval, as it might conflict with the user's privacy interests or 1736 their site's security policy. It is strongly recommended that the 1737 user be able to disable, enable, and modify the value of this field 1738 at any time prior to a request. 1740 9.4. Location 1742 The "Location" header field is used to identify a newly created 1743 resource, or to redirect the recipient to a different location for 1744 completion of the request. 1746 For 201 (Created) responses, the Location is the URI of the new 1747 resource which was created by the request. For 3xx responses, the 1748 location SHOULD indicate the server's preferred URI for automatic 1749 redirection to the resource. 1751 The field value consists of a single URI-reference. When it has the 1752 form of a relative reference ([RFC3986], Section 4.2), the final 1753 value is computed by resolving it against the effective request URI 1754 ([RFC3986], Section 5). 1756 Location = URI-reference 1758 Examples are: 1760 Location: http://www.example.org/pub/WWW/People.html#tim 1762 Location: /index.html 1764 There are circumstances in which a fragment identifier in a Location 1765 URI would not be appropriate: 1767 o With a 201 Created response, because in this usage the Location 1768 header field specifies the URI for the entire created resource. 1770 o With 305 Use Proxy. 1772 Note: This specification does not define precedence rules for the 1773 case where the original URI, as navigated to by the user agent, 1774 and the Location header field value both contain fragment 1775 identifiers. Thus be aware that including fragment identifiers 1776 might inconvenience anyone relying on the semantics of the 1777 original URI's fragment identifier. 1779 Note: The Content-Location header field (Section 6.7 of [Part3]) 1780 differs from Location in that the Content-Location identifies the 1781 most specific resource corresponding to the enclosed 1782 representation. It is therefore possible for a response to 1783 contain header fields for both Location and Content-Location. 1785 9.5. Max-Forwards 1787 The "Max-Forwards" header field provides a mechanism with the TRACE 1788 (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number 1789 of times that the request is forwarded by proxies. This can be 1790 useful when the client is attempting to trace a request which appears 1791 to be failing or looping in mid-chain. 1793 Max-Forwards = 1*DIGIT 1795 The Max-Forwards value is a decimal integer indicating the remaining 1796 number of times this request message can be forwarded. 1798 Each recipient of a TRACE or OPTIONS request containing a Max- 1799 Forwards header field MUST check and update its value prior to 1800 forwarding the request. If the received value is zero (0), the 1801 recipient MUST NOT forward the request; instead, it MUST respond as 1802 the final recipient. If the received Max-Forwards value is greater 1803 than zero, then the forwarded message MUST contain an updated Max- 1804 Forwards field with a value decremented by one (1). 1806 The Max-Forwards header field MAY be ignored for all other request 1807 methods. 1809 9.6. Referer 1811 The "Referer" [sic] header field allows the client to specify the URI 1812 of the resource from which the effective request URI was obtained 1813 (the "referrer", although the header field is misspelled.). 1815 The Referer header field allows servers to generate lists of back- 1816 links to resources for interest, logging, optimized caching, etc. It 1817 also allows obsolete or mistyped links to be traced for maintenance. 1818 Some servers use Referer as a means of controlling where they allow 1819 links from (so-called "deep linking"), but legitimate requests do not 1820 always contain a Referer header field. 1822 If the effective request URI was obtained from a source that does not 1823 have its own URI (e.g., input from the user keyboard), the Referer 1824 field MUST either be sent with the value "about:blank", or not be 1825 sent at all. Note that this requirement does not apply to sources 1826 with non-HTTP URIs (e.g., FTP). 1828 Referer = absolute-URI / partial-URI 1830 Example: 1832 Referer: http://www.example.org/hypertext/Overview.html 1834 If the field value is a relative URI, it SHOULD be interpreted 1835 relative to the effective request URI. The URI MUST NOT include a 1836 fragment. See Section 11.2 for security considerations. 1838 9.7. Retry-After 1840 The header "Retry-After" field can be used with a 503 (Service 1841 Unavailable) response to indicate how long the service is expected to 1842 be unavailable to the requesting client. This field MAY also be used 1843 with any 3xx (Redirection) response to indicate the minimum time the 1844 user-agent is asked wait before issuing the redirected request. 1846 The value of this field can be either an HTTP-date or an integer 1847 number of seconds (in decimal) after the time of the response. 1849 Retry-After = HTTP-date / delta-seconds 1851 Time spans are non-negative decimal integers, representing time in 1852 seconds. 1854 delta-seconds = 1*DIGIT 1856 Two examples of its use are 1858 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1859 Retry-After: 120 1861 In the latter example, the delay is 2 minutes. 1863 9.8. Server 1865 The "Server" header field contains information about the software 1866 used by the origin server to handle the request. 1868 The field can contain multiple product tokens (Section 6.3 of 1869 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server 1870 and any significant subproducts. The product tokens are listed in 1871 order of their significance for identifying the application. 1873 Server = product *( RWS ( product / comment ) ) 1875 Example: 1877 Server: CERN/3.0 libwww/2.17 1879 If the response is being forwarded through a proxy, the proxy 1880 application MUST NOT modify the Server header field. Instead, it 1881 MUST include a Via field (as described in Section 9.9 of [Part1]). 1883 Note: Revealing the specific software version of the server might 1884 allow the server machine to become more vulnerable to attacks 1885 against software that is known to contain security holes. Server 1886 implementors are encouraged to make this field a configurable 1887 option. 1889 9.9. User-Agent 1891 The "User-Agent" header field contains information about the user 1892 agent originating the request. User agents SHOULD include this field 1893 with requests. 1895 Typically, it is used for statistical purposes, the tracing of 1896 protocol violations, and tailoring responses to avoid particular user 1897 agent limitations. 1899 The field can contain multiple product tokens (Section 6.3 of 1900 [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent 1901 and its significant subproducts. By convention, the product tokens 1902 are listed in order of their significance for identifying the 1903 application. 1905 Because this field is usually sent on every request a user agent 1906 makes, implementations are encouraged not to include needlessly fine- 1907 grained detail, and to limit (or even prohibit) the addition of 1908 subproducts by third parties. Overly long and detailed User-Agent 1909 field values make requests larger and can also be used to identify 1910 ("fingerprint") the user against their wishes. 1912 Likewise, implementations are encouraged not to use the product 1913 tokens of other implementations in order to declare compatibility 1914 with them, as this circumvents the purpose of the field. Finally, 1915 they are encouraged not to use comments to identify products; doing 1916 so makes the field value more difficult to parse. 1918 User-Agent = product *( RWS ( product / comment ) ) 1920 Example: 1922 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1924 10. IANA Considerations 1926 10.1. Method Registry 1928 The registration procedure for HTTP request methods is defined by 1929 Section 2.2 of this document. 1931 The HTTP Method Registry shall be created at 1932 and be populated with 1933 the registrations below: 1935 +---------+------+-------------+ 1936 | Method | Safe | Reference | 1937 +---------+------+-------------+ 1938 | CONNECT | no | Section 7.9 | 1939 | DELETE | no | Section 7.7 | 1940 | GET | yes | Section 7.3 | 1941 | HEAD | yes | Section 7.4 | 1942 | OPTIONS | yes | Section 7.2 | 1943 | POST | no | Section 7.5 | 1944 | PUT | no | Section 7.6 | 1945 | TRACE | yes | Section 7.8 | 1946 +---------+------+-------------+ 1948 10.2. Status Code Registry 1950 The registration procedure for HTTP Status Codes -- previously 1951 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2 1952 of this document. 1954 The HTTP Status Code Registry located at 1955 shall be updated 1956 with the registrations below: 1958 +-------+-------------------------------+----------------+ 1959 | Value | Description | Reference | 1960 +-------+-------------------------------+----------------+ 1961 | 100 | Continue | Section 8.1.1 | 1962 | 101 | Switching Protocols | Section 8.1.2 | 1963 | 200 | OK | Section 8.2.1 | 1964 | 201 | Created | Section 8.2.2 | 1965 | 202 | Accepted | Section 8.2.3 | 1966 | 203 | Non-Authoritative Information | Section 8.2.4 | 1967 | 204 | No Content | Section 8.2.5 | 1968 | 205 | Reset Content | Section 8.2.6 | 1969 | 300 | Multiple Choices | Section 8.3.1 | 1970 | 301 | Moved Permanently | Section 8.3.2 | 1971 | 302 | Found | Section 8.3.3 | 1972 | 303 | See Other | Section 8.3.4 | 1973 | 305 | Use Proxy | Section 8.3.6 | 1974 | 306 | (Unused) | Section 8.3.7 | 1975 | 307 | Temporary Redirect | Section 8.3.8 | 1976 | 400 | Bad Request | Section 8.4.1 | 1977 | 402 | Payment Required | Section 8.4.3 | 1978 | 403 | Forbidden | Section 8.4.4 | 1979 | 404 | Not Found | Section 8.4.5 | 1980 | 405 | Method Not Allowed | Section 8.4.6 | 1981 | 406 | Not Acceptable | Section 8.4.7 | 1982 | 407 | Proxy Authentication Required | Section 8.4.8 | 1983 | 408 | Request Timeout | Section 8.4.9 | 1984 | 409 | Conflict | Section 8.4.10 | 1985 | 410 | Gone | Section 8.4.11 | 1986 | 411 | Length Required | Section 8.4.12 | 1987 | 413 | Request Entity Too Large | Section 8.4.14 | 1988 | 414 | URI Too Long | Section 8.4.15 | 1989 | 415 | Unsupported Media Type | Section 8.4.16 | 1990 | 417 | Expectation Failed | Section 8.4.18 | 1991 | 426 | Upgrade Required | Section 8.4.19 | 1992 | 500 | Internal Server Error | Section 8.5.1 | 1993 | 501 | Not Implemented | Section 8.5.2 | 1994 | 502 | Bad Gateway | Section 8.5.3 | 1995 | 503 | Service Unavailable | Section 8.5.4 | 1996 | 504 | Gateway Timeout | Section 8.5.5 | 1997 | 505 | HTTP Version Not Supported | Section 8.5.6 | 1998 +-------+-------------------------------+----------------+ 2000 10.3. Header Field Registration 2002 The Message Header Field Registry located at shall be 2004 updated with the permanent registrations below (see [RFC3864]): 2006 +-------------------+----------+----------+-------------+ 2007 | Header Field Name | Protocol | Status | Reference | 2008 +-------------------+----------+----------+-------------+ 2009 | Allow | http | standard | Section 9.1 | 2010 | Expect | http | standard | Section 9.2 | 2011 | From | http | standard | Section 9.3 | 2012 | Location | http | standard | Section 9.4 | 2013 | Max-Forwards | http | standard | Section 9.5 | 2014 | Referer | http | standard | Section 9.6 | 2015 | Retry-After | http | standard | Section 9.7 | 2016 | Server | http | standard | Section 9.8 | 2017 | User-Agent | http | standard | Section 9.9 | 2018 +-------------------+----------+----------+-------------+ 2020 The change controller is: "IETF (iesg@ietf.org) - Internet 2021 Engineering Task Force". 2023 11. Security Considerations 2025 This section is meant to inform application developers, information 2026 providers, and users of the security limitations in HTTP/1.1 as 2027 described by this document. The discussion does not include 2028 definitive solutions to the problems revealed, though it does make 2029 some suggestions for reducing security risks. 2031 11.1. Transfer of Sensitive Information 2033 Like any generic data transfer protocol, HTTP cannot regulate the 2034 content of the data that is transferred, nor is there any a priori 2035 method of determining the sensitivity of any particular piece of 2036 information within the context of any given request. Therefore, 2037 applications SHOULD supply as much control over this information as 2038 possible to the provider of that information. Four header fields are 2039 worth special mention in this context: Server, Via, Referer and From. 2041 Revealing the specific software version of the server might allow the 2042 server machine to become more vulnerable to attacks against software 2043 that is known to contain security holes. Implementors SHOULD make 2044 the Server header field a configurable option. 2046 Proxies which serve as a portal through a network firewall SHOULD 2047 take special precautions regarding the transfer of header information 2048 that identifies the hosts behind the firewall. In particular, they 2049 SHOULD remove, or replace with sanitized versions, any Via fields 2050 generated behind the firewall. 2052 The Referer header field allows reading patterns to be studied and 2053 reverse links drawn. Although it can be very useful, its power can 2054 be abused if user details are not separated from the information 2055 contained in the Referer. Even when the personal information has 2056 been removed, the Referer header field might indicate a private 2057 document's URI whose publication would be inappropriate. 2059 The information sent in the From field might conflict with the user's 2060 privacy interests or their site's security policy, and hence it 2061 SHOULD NOT be transmitted without the user being able to disable, 2062 enable, and modify the contents of the field. The user MUST be able 2063 to set the contents of this field within a user preference or 2064 application defaults configuration. 2066 We suggest, though do not require, that a convenient toggle interface 2067 be provided for the user to enable or disable the sending of From and 2068 Referer information. 2070 The User-Agent (Section 9.9) or Server (Section 9.8) header fields 2071 can sometimes be used to determine that a specific client or server 2072 have a particular security hole which might be exploited. 2073 Unfortunately, this same information is often used for other valuable 2074 purposes for which HTTP currently has no better mechanism. 2076 Furthermore, the User-Agent header field may contain enough entropy 2077 to be used, possibly in conjunction with other material, to uniquely 2078 identify the user. 2080 Some request methods, like TRACE (Section 7.8), expose information 2081 that was sent in request header fields within the body of their 2082 response. Clients SHOULD be careful with sensitive information, like 2083 Cookies, Authorization credentials, and other header fields that 2084 might be used to collect data from the client. 2086 11.2. Encoding Sensitive Information in URIs 2088 Because the source of a link might be private information or might 2089 reveal an otherwise private information source, it is strongly 2090 recommended that the user be able to select whether or not the 2091 Referer field is sent. For example, a browser client could have a 2092 toggle switch for browsing openly/anonymously, which would 2093 respectively enable/disable the sending of Referer and From 2094 information. 2096 Clients SHOULD NOT include a Referer header field in a (non-secure) 2097 HTTP request if the referring page was transferred with a secure 2098 protocol. 2100 Authors of services SHOULD NOT use GET-based forms for the submission 2101 of sensitive data because that data will be placed in the request- 2102 target. Many existing servers, proxies, and user agents log or 2103 display the request-target in places where it might be visible to 2104 third parties. Such services can use POST-based form submission 2105 instead. 2107 11.3. Location Headers and Spoofing 2109 If a single server supports multiple organizations that do not trust 2110 one another, then it MUST check the values of Location and Content- 2111 Location header fields in responses that are generated under control 2112 of said organizations to make sure that they do not attempt to 2113 invalidate resources over which they have no authority. 2115 11.4. Security Considerations for CONNECT 2117 Since tunneled data is opaque to the proxy, there are additional 2118 risks to tunneling to other well-known or reserved ports. A HTTP 2119 client CONNECTing to port 25 could relay spam via SMTP, for example. 2120 As such, proxies SHOULD restrict CONNECT access to a small number of 2121 known ports. 2123 12. Acknowledgments 2125 13. References 2127 13.1. Normative References 2129 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2130 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2131 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 2132 and Message Parsing", draft-ietf-httpbis-p1-messaging-14 2133 (work in progress), April 2011. 2135 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2136 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2137 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2138 and Content Negotiation", draft-ietf-httpbis-p3-payload-14 2139 (work in progress), April 2011. 2141 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2142 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2143 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 2144 Requests", draft-ietf-httpbis-p4-conditional-14 (work in 2145 progress), April 2011. 2147 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2148 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2149 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2150 Partial Responses", draft-ietf-httpbis-p5-range-14 (work 2151 in progress), April 2011. 2153 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2154 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2155 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2156 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in 2157 progress), April 2011. 2159 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2160 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2161 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 2162 draft-ietf-httpbis-p7-auth-14 (work in progress), 2163 April 2011. 2165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2166 Requirement Levels", BCP 14, RFC 2119, March 1997. 2168 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2169 Resource Identifier (URI): Generic Syntax", STD 66, 2170 RFC 3986, January 2005. 2172 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2173 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2175 13.2. Informative References 2177 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2178 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2180 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2181 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2182 RFC 2068, January 1997. 2184 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2185 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2186 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2188 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 2189 HTTP/1.1", RFC 2817, May 2000. 2191 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2192 Procedures for Message Header Fields", BCP 90, RFC 3864, 2193 September 2004. 2195 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2196 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2197 May 2008. 2199 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2200 October 2008. 2202 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 2203 RFC 5789, March 2010. 2205 Appendix A. Changes from RFC 2616 2207 This document takes over the Status Code Registry, previously defined 2208 in Section 7.1 of [RFC2817]. (Section 4.2) 2210 Clarify definition of POST. (Section 7.5) 2212 Remove requirement to handle all Content-* header fields; ban use of 2213 Content-Range with PUT. (Section 7.6) 2215 Take over definition of CONNECT method from [RFC2817]. (Section 7.9) 2217 Failed to consider that there are many other request methods that are 2218 safe to automatically redirect, and further that the user agent is 2219 able to make that determination based on the request method 2220 semantics. (Sections 8.3.2, 8.3.3 and 8.3.8) 2222 Deprecate 305 Use Proxy status code, because user agents did not 2223 implement it. It used to indicate that the target resource must be 2224 accessed through the proxy given by the Location field. The Location 2225 field gave the URI of the proxy. The recipient was expected to 2226 repeat this single request via the proxy. (Section 8.3.6) 2228 Define status 426 (Upgrade Required) (this was incorporated from 2229 [RFC2817]). (Section 8.4.19) 2231 Change ABNF productions for header fields to only define the field 2232 value. (Section 9) 2234 Reclassify "Allow" as response header field, removing the option to 2235 specify it in a PUT request. Relax the server requirement on the 2236 contents of the Allow header field and remove requirement on clients 2237 to always trust the header field value. (Section 9.1) 2239 Correct syntax of Location header field to allow URI references 2240 (including relative references and fragments), as referred symbol 2241 "absoluteURI" wasn't what was expected, and add some clarifications 2242 as to when use of fragments would not be appropriate. (Section 9.4) 2244 Restrict Max-Forwards header field to OPTIONS and TRACE (previously, 2245 extension methods could have used it as well). (Section 9.5) 2246 Allow Referer field value of "about:blank" as alternative to not 2247 specifying it. (Section 9.6) 2249 In the description of the Server header field, the Via field was 2250 described as a SHOULD. The requirement was and is stated correctly 2251 in the description of the Via header field in Section 9.9 of [Part1]. 2252 (Section 9.8) 2254 Appendix B. Collected ABNF 2255 Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2257 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2259 From = mailbox 2261 HTTP-date = 2263 Location = URI-reference 2265 Max-Forwards = 1*DIGIT 2266 Method = token 2268 OWS = 2270 RWS = 2271 Reason-Phrase = *( WSP / VCHAR / obs-text ) 2272 Referer = absolute-URI / partial-URI 2273 Retry-After = HTTP-date / delta-seconds 2275 Server = product *( RWS ( product / comment ) ) 2276 Status-Code = 3DIGIT 2278 URI-reference = 2279 User-Agent = product *( RWS ( product / comment ) ) 2281 absolute-URI = 2283 comment = 2285 delta-seconds = 1*DIGIT 2287 expect-params = ";" token [ "=" ( token / quoted-string ) ] 2288 expectation = "100-continue" / expectation-extension 2289 expectation-extension = token [ "=" ( token / quoted-string ) 2290 *expect-params ] 2292 mailbox = 2294 obs-text = 2296 partial-URI = 2297 product = 2299 quoted-string = 2301 token = 2302 ABNF diagnostics: 2304 ; Allow defined but not used 2305 ; Expect defined but not used 2306 ; From defined but not used 2307 ; Location defined but not used 2308 ; Max-Forwards defined but not used 2309 ; Reason-Phrase defined but not used 2310 ; Referer defined but not used 2311 ; Retry-After defined but not used 2312 ; Server defined but not used 2313 ; Status-Code defined but not used 2314 ; User-Agent defined but not used 2316 Appendix C. Change Log (to be removed by RFC Editor before publication) 2318 C.1. Since RFC 2616 2320 Extracted relevant partitions from [RFC2616]. 2322 C.2. Since draft-ietf-httpbis-p2-semantics-00 2324 Closed issues: 2326 o : "Via is a MUST" 2327 () 2329 o : "Fragments 2330 allowed in Location" 2331 () 2333 o : "Safe Methods 2334 vs Redirection" () 2336 o : "Revise 2337 description of the POST method" 2338 () 2340 o : "Normative and 2341 Informative references" 2343 o : "RFC2606 2344 Compliance" 2346 o : "Informative 2347 references" 2349 o : "Redundant 2350 cross-references" 2352 Other changes: 2354 o Move definitions of 304 and 412 condition codes to [Part4] 2356 C.3. Since draft-ietf-httpbis-p2-semantics-01 2358 Closed issues: 2360 o : "PUT side 2361 effects" 2363 o : "Duplicate Host 2364 header requirements" 2366 Ongoing work on ABNF conversion 2367 (): 2369 o Move "Product Tokens" section (back) into Part 1, as "token" is 2370 used in the definition of the Upgrade header field. 2372 o Add explicit references to BNF syntax and rules imported from 2373 other parts of the specification. 2375 o Copy definition of delta-seconds from Part6 instead of referencing 2376 it. 2378 C.4. Since draft-ietf-httpbis-p2-semantics-02 2380 Closed issues: 2382 o : "Requiring 2383 Allow in 405 responses" 2385 o : "Status Code 2386 Registry" 2388 o : "Redirection 2389 vs. Location" 2391 o : "Cacheability 2392 of 303 response" 2394 o : "305 Use Proxy" 2395 o : 2396 "Classification for Allow header" 2398 o : "PUT - 'store 2399 under' vs 'store at'" 2401 Ongoing work on IANA Message Header Field Registration 2402 (): 2404 o Reference RFC 3984, and update header field registrations for 2405 headers defined in this document. 2407 Ongoing work on ABNF conversion 2408 (): 2410 o Replace string literals when the string really is case-sensitive 2411 (method). 2413 C.5. Since draft-ietf-httpbis-p2-semantics-03 2415 Closed issues: 2417 o : "OPTIONS 2418 request bodies" 2420 o : "Description 2421 of CONNECT should refer to RFC2817" 2423 o : "Location 2424 Content-Location reference request/response mixup" 2426 Ongoing work on Method Registry 2427 (): 2429 o Added initial proposal for registration process, plus initial 2430 content (non-HTTP/1.1 methods to be added by a separate 2431 specification). 2433 C.6. Since draft-ietf-httpbis-p2-semantics-04 2435 Closed issues: 2437 o : "Content-*" 2439 o : "RFC 2822 is 2440 updated by RFC 5322" 2442 Ongoing work on ABNF conversion 2443 (): 2445 o Use "/" instead of "|" for alternatives. 2447 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2448 whitespace ("OWS") and required whitespace ("RWS"). 2450 o Rewrite ABNFs to spell out whitespace rules, factor out header 2451 field value format definitions. 2453 C.7. Since draft-ietf-httpbis-p2-semantics-05 2455 Closed issues: 2457 o : "Reason-Phrase 2458 BNF" 2460 Final work on ABNF conversion 2461 (): 2463 o Add appendix containing collected and expanded ABNF, reorganize 2464 ABNF introduction. 2466 C.8. Since draft-ietf-httpbis-p2-semantics-06 2468 Closed issues: 2470 o : "Clarify when 2471 Referer is sent" 2473 o : "status codes 2474 vs methods" 2476 o : "Do not 2477 require "updates" relation for specs that register status codes or 2478 method names" 2480 C.9. Since draft-ietf-httpbis-p2-semantics-07 2482 Closed issues: 2484 o : "Idempotency" 2486 o : "TRACE security 2487 considerations" 2489 o : "Clarify rules 2490 for determining what entities a response carries" 2492 o : "update note 2493 citing RFC 1945 and 2068" 2495 o : "update note 2496 about redirect limit" 2498 o : "Location 2499 header ABNF should use 'URI'" 2501 o : "fragments in 2502 Location vs status 303" 2504 o : "move IANA 2505 registrations for optional status codes" 2507 Partly resolved issues: 2509 o : "Are OPTIONS 2510 and TRACE safe?" 2512 C.10. Since draft-ietf-httpbis-p2-semantics-08 2514 Closed issues: 2516 o : "Safe Methods 2517 vs Redirection" (we missed the introduction to the 3xx status 2518 codes when fixing this previously) 2520 C.11. Since draft-ietf-httpbis-p2-semantics-09 2522 Closed issues: 2524 o : "Fragment 2525 combination / precedence during redirects" 2527 Partly resolved issues: 2529 o : "Location 2530 header payload handling" 2532 o : "Term for the 2533 requested resource's URI" 2535 C.12. Since draft-ietf-httpbis-p2-semantics-10 2537 Closed issues: 2539 o : "Clarify 2540 'Requested Variant'" 2542 o : "Clarify 2543 entity / representation / variant terminology" 2545 o : "Methods and 2546 Caching" 2548 o : "OPTIONS vs 2549 Max-Forwards" 2551 o : "Status codes 2552 and caching" 2554 o : "consider 2555 removing the 'changes from 2068' sections" 2557 C.13. Since draft-ietf-httpbis-p2-semantics-11 2559 Closed issues: 2561 o : 2562 "Considerations for new status codes" 2564 o : 2565 "Considerations for new methods" 2567 o : "User-Agent 2568 guidelines" (relating to the 'User-Agent' header field) 2570 C.14. Since draft-ietf-httpbis-p2-semantics-12 2572 Closed issues: 2574 o : "Fragment 2575 combination / precedence during redirects" (added warning about 2576 having a fragid on the redirect may cause inconvenience in some 2577 cases) 2579 o : "Content-* vs. 2580 PUT" 2582 o : "205 Bodies" 2584 o : "Understanding 2585 Content-* on non-PUT requests" 2587 o : "Content-*" 2589 o : "Header type 2590 defaulting" 2592 o : "PUT - 'store 2593 under' vs 'store at'" 2595 o : "duplicate 2596 ABNF for Reason-Phrase" 2598 o : "Note special 2599 status of Content-* prefix in header registration procedures" 2601 o : "Max-Forwards 2602 vs extension methods" 2604 o : "What is the 2605 value space of HTTP status codes?" (actually fixed in 2606 draft-ietf-httpbis-p2-semantics-11) 2608 o : "Header 2609 Classification" 2611 o : "PUT side 2612 effect: invalidation or just stale?" 2614 o : "proxies not 2615 supporting certain methods" 2617 o : "Migrate 2618 CONNECT from RFC2817 to p2" 2620 o : "Migrate 2621 Upgrade details from RFC2817" 2623 o : "clarify PUT 2624 semantics'" 2626 o : "duplicate 2627 ABNF for 'Method'" 2629 o : "untangle 2630 ABNFs for header fields" 2632 C.15. Since draft-ietf-httpbis-p2-semantics-13 2634 Closed issues: 2636 o : "untangle 2637 ABNFs for header fields" 2639 o : "message-body 2640 in CONNECT request" 2642 Index 2644 1 2645 100 Continue (status code) 23 2646 101 Switching Protocols (status code) 23 2648 2 2649 200 OK (status code) 24 2650 201 Created (status code) 24 2651 202 Accepted (status code) 25 2652 203 Non-Authoritative Information (status code) 25 2653 204 No Content (status code) 25 2654 205 Reset Content (status code) 26 2655 206 Partial Content (status code) 26 2657 3 2658 300 Multiple Choices (status code) 27 2659 301 Moved Permanently (status code) 27 2660 302 Found (status code) 28 2661 303 See Other (status code) 28 2662 304 Not Modified (status code) 29 2663 305 Use Proxy (status code) 29 2664 306 (Unused) (status code) 29 2665 307 Temporary Redirect (status code) 29 2667 4 2668 400 Bad Request (status code) 30 2669 401 Unauthorized (status code) 30 2670 402 Payment Required (status code) 30 2671 403 Forbidden (status code) 30 2672 404 Not Found (status code) 31 2673 405 Method Not Allowed (status code) 31 2674 406 Not Acceptable (status code) 31 2675 407 Proxy Authentication Required (status code) 32 2676 408 Request Timeout (status code) 32 2677 409 Conflict (status code) 32 2678 410 Gone (status code) 32 2679 411 Length Required (status code) 33 2680 412 Precondition Failed (status code) 33 2681 413 Request Entity Too Large (status code) 33 2682 414 URI Too Long (status code) 33 2683 415 Unsupported Media Type (status code) 33 2684 416 Requested Range Not Satisfiable (status code) 34 2685 417 Expectation Failed (status code) 34 2686 426 Upgrade Required (status code) 34 2688 5 2689 500 Internal Server Error (status code) 34 2690 501 Not Implemented (status code) 35 2691 502 Bad Gateway (status code) 35 2692 503 Service Unavailable (status code) 35 2693 504 Gateway Timeout (status code) 35 2694 505 HTTP Version Not Supported (status code) 35 2696 A 2697 Allow header field 36 2699 C 2700 CONNECT method 21 2702 D 2703 DELETE method 20 2705 E 2706 Expect header field 36 2708 F 2709 From header field 37 2711 G 2712 GET method 16 2713 Grammar 2714 Allow 36 2715 delta-seconds 40 2716 Expect 36 2717 expect-params 36 2718 expectation 36 2719 expectation-extension 36 2720 extension-code 10 2721 From 37 2722 Location 38 2723 Max-Forwards 39 2724 Method 7 2725 Reason-Phrase 10 2726 Referer 39 2727 Retry-After 40 2728 Server 40 2729 Status-Code 10 2730 User-Agent 41 2732 H 2733 HEAD method 17 2734 Header Fields 2735 Allow 36 2736 Expect 36 2737 From 37 2738 Location 38 2739 Max-Forwards 39 2740 Referer 39 2741 Retry-After 40 2742 Server 40 2743 User-Agent 41 2745 I 2746 Idempotent Methods 15 2748 L 2749 Location header field 38 2751 M 2752 Max-Forwards header field 39 2753 Methods 2754 CONNECT 21 2755 DELETE 20 2756 GET 16 2757 HEAD 17 2758 OPTIONS 15 2759 POST 17 2760 PUT 18 2761 TRACE 21 2763 O 2764 OPTIONS method 15 2766 P 2767 POST method 17 2768 PUT method 18 2770 R 2771 Referer header field 39 2772 Retry-After header field 40 2774 S 2775 Safe Methods 14 2776 Server header field 40 2777 Status Codes 2778 100 Continue 23 2779 101 Switching Protocols 23 2780 200 OK 24 2781 201 Created 24 2782 202 Accepted 25 2783 203 Non-Authoritative Information 25 2784 204 No Content 25 2785 205 Reset Content 26 2786 206 Partial Content 26 2787 300 Multiple Choices 27 2788 301 Moved Permanently 27 2789 302 Found 28 2790 303 See Other 28 2791 304 Not Modified 29 2792 305 Use Proxy 29 2793 306 (Unused) 29 2794 307 Temporary Redirect 29 2795 400 Bad Request 30 2796 401 Unauthorized 30 2797 402 Payment Required 30 2798 403 Forbidden 30 2799 404 Not Found 31 2800 405 Method Not Allowed 31 2801 406 Not Acceptable 31 2802 407 Proxy Authentication Required 32 2803 408 Request Timeout 32 2804 409 Conflict 32 2805 410 Gone 32 2806 411 Length Required 33 2807 412 Precondition Failed 33 2808 413 Request Entity Too Large 33 2809 414 URI Too Long 33 2810 415 Unsupported Media Type 33 2811 416 Requested Range Not Satisfiable 34 2812 417 Expectation Failed 34 2813 426 Upgrade Required 34 2814 500 Internal Server Error 34 2815 501 Not Implemented 35 2816 502 Bad Gateway 35 2817 503 Service Unavailable 35 2818 504 Gateway Timeout 35 2819 505 HTTP Version Not Supported 35 2821 T 2822 TRACE method 21 2824 U 2825 User-Agent header field 41 2827 Authors' Addresses 2829 Roy T. Fielding (editor) 2830 Adobe Systems Incorporated 2831 345 Park Ave 2832 San Jose, CA 95110 2833 USA 2835 EMail: fielding@gbiv.com 2836 URI: http://roy.gbiv.com/ 2838 Jim Gettys 2839 Alcatel-Lucent Bell Labs 2840 21 Oak Knoll Road 2841 Carlisle, MA 01741 2842 USA 2844 EMail: jg@freedesktop.org 2845 URI: http://gettys.wordpress.com/ 2847 Jeffrey C. Mogul 2848 Hewlett-Packard Company 2849 HP Labs, Large Scale Systems Group 2850 1501 Page Mill Road, MS 1177 2851 Palo Alto, CA 94304 2852 USA 2854 EMail: JeffMogul@acm.org 2856 Henrik Frystyk Nielsen 2857 Microsoft Corporation 2858 1 Microsoft Way 2859 Redmond, WA 98052 2860 USA 2862 EMail: henrikn@microsoft.com 2863 Larry Masinter 2864 Adobe Systems Incorporated 2865 345 Park Ave 2866 San Jose, CA 95110 2867 USA 2869 EMail: LMM@acm.org 2870 URI: http://larry.masinter.net/ 2872 Paul J. Leach 2873 Microsoft Corporation 2874 1 Microsoft Way 2875 Redmond, WA 98052 2877 EMail: paulle@microsoft.com 2879 Tim Berners-Lee 2880 World Wide Web Consortium 2881 MIT Computer Science and Artificial Intelligence Laboratory 2882 The Stata Center, Building 32 2883 32 Vassar Street 2884 Cambridge, MA 02139 2885 USA 2887 EMail: timbl@w3.org 2888 URI: http://www.w3.org/People/Berners-Lee/ 2890 Yves Lafon (editor) 2891 World Wide Web Consortium 2892 W3C / ERCIM 2893 2004, rte des Lucioles 2894 Sophia-Antipolis, AM 06902 2895 France 2897 EMail: ylafon@w3.org 2898 URI: http://www.raubacapeu.net/people/yves/ 2899 Julian F. Reschke (editor) 2900 greenbytes GmbH 2901 Hafenweg 16 2902 Muenster, NW 48155 2903 Germany 2905 Phone: +49 251 2807760 2906 Fax: +49 251 2807761 2907 EMail: julian.reschke@greenbytes.de 2908 URI: http://greenbytes.de/tech/webdav/