idnits 2.17.1 draft-ietf-httpbis-p2-semantics-17.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 (October 31, 2011) is 4560 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-17 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-17 -- 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) -- Obsolete informational reference (is this intentional?): RFC 5987 (Obsoleted by RFC 8187) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: May 3, 2012 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 October 31, 2011 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-17 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext 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. 34 Part 2 defines the semantics of HTTP messages as expressed by request 35 methods, request header fields, response status codes, and response 36 header fields. 38 Editorial Note (To be removed by RFC Editor) 40 Discussion of this draft should take place on the HTTPBIS working 41 group mailing list (ietf-http-wg@w3.org), which is archived at 42 . 44 The current issues list is at 45 and related 46 documents (including fancy diffs) can be found at 47 . 49 The changes in this draft are summarized in Appendix C.18. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on May 3, 2012. 68 Copyright Notice 70 Copyright (c) 2011 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 9 106 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 107 3.1. Considerations for Creating Header Fields . . . . . . . . 9 108 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11 109 3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12 110 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12 111 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13 112 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15 113 4.2.1. Considerations for New Status Codes . . . . . . . . . 15 114 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16 115 5.1. Identifying the Resource Associated with a 116 Representation . . . . . . . . . . . . . . . . . . . . . . 16 117 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17 118 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17 119 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17 120 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17 121 6.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18 122 6.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 123 6.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 124 6.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 125 6.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 126 6.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 6.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 128 6.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 24 129 6.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 25 130 7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 25 131 7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26 132 7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26 133 7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 26 134 7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 27 135 7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27 136 7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27 137 7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28 138 7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28 139 7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28 140 7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29 141 7.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 29 142 7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29 143 7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 30 144 7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31 145 7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32 146 7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32 147 7.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 33 148 7.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33 149 7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33 150 7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33 151 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34 152 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34 153 7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34 154 7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34 155 7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34 156 7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35 157 7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35 158 7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35 159 7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 35 160 7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36 161 7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36 162 7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36 163 7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37 164 7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37 165 7.4.14. 413 Request Representation Too Large . . . . . . . . . 37 166 7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37 167 7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37 168 7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38 169 7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38 170 7.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 38 171 7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 38 172 7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 38 173 7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 39 174 7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 39 175 7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 39 176 7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 39 177 7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 39 178 8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 40 179 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42 180 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42 181 9.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 182 9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44 183 9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 184 9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45 185 9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46 186 9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47 187 9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47 188 9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48 189 9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48 190 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 191 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49 192 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 49 193 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51 194 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 195 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51 196 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52 197 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53 198 11.4. Security Considerations for CONNECT . . . . . . . . . . . 53 199 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 200 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 201 13.1. Normative References . . . . . . . . . . . . . . . . . . . 53 202 13.2. Informative References . . . . . . . . . . . . . . . . . . 54 203 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55 204 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 205 Appendix C. Change Log (to be removed by RFC Editor before 206 publication) . . . . . . . . . . . . . . . . . . . . 59 207 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59 208 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59 209 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 59 210 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60 211 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61 212 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61 213 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 61 214 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62 215 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62 216 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63 217 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63 218 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63 219 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64 220 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64 221 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 65 222 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66 223 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66 224 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66 225 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 227 1. Introduction 229 This document defines HTTP/1.1 request and response semantics. Each 230 HTTP message, as defined in [Part1], is in the form of either a 231 request or a response. An HTTP server listens on a connection for 232 HTTP requests and responds to each request, in the order received on 233 that connection, with one or more HTTP response messages. This 234 document defines the commonly agreed upon semantics of the HTTP 235 uniform interface, the intentions defined by each request method, and 236 the various response messages that might be expected as a result of 237 applying that method to the target resource. 239 This document is currently disorganized in order to minimize the 240 changes between drafts and enable reviewers to see the smaller errata 241 changes. A future draft will reorganize the sections to better 242 reflect the content. In particular, the sections will be ordered 243 according to the typical processing of an HTTP request message (after 244 message parsing): resource mapping, methods, request modifying header 245 fields, response status, status modifying header fields, and resource 246 metadata. The current mess reflects how widely dispersed these 247 topics and associated requirements had become in [RFC2616]. 249 1.1. Conformance and Error Handling 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC2119]. 255 This document defines conformance criteria for several roles in HTTP 256 communication, including Senders, Recipients, Clients, Servers, User- 257 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 258 Section 2 of [Part1] for definitions of these terms. 260 An implementation is considered conformant if it complies with all of 261 the requirements associated with its role(s). Note that SHOULD-level 262 requirements are relevant here, unless one of the documented 263 exceptions is applicable. 265 This document also uses ABNF to define valid protocol elements 266 (Section 1.2). In addition to the prose requirements placed upon 267 them, Senders MUST NOT generate protocol elements that are invalid. 269 Unless noted otherwise, Recipients MAY take steps to recover a usable 270 protocol element from an invalid construct. However, HTTP does not 271 define specific error handling mechanisms, except in cases where it 272 has direct impact on security. This is because different uses of the 273 protocol require different error handling strategies; for example, a 274 Web browser may wish to transparently recover from a response where 275 the Location header field doesn't parse according to the ABNF, 276 whereby in a systems control protocol using HTTP, this type of error 277 recovery could lead to dangerous consequences. 279 1.2. Syntax Notation 281 This specification uses the ABNF syntax defined in Section 1.2 of 282 [Part1] (which extends the syntax defined in [RFC5234] with a list 283 rule). Appendix B shows the collected ABNF, with the list rule 284 expanded. 286 The following core rules are included by reference, as defined in 287 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 288 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 289 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 290 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 291 visible US-ASCII character). 293 1.2.1. Core Rules 295 The core rules below are defined in [Part1]: 297 OWS = 298 RWS = 299 obs-text = 300 quoted-string = 301 token = 303 1.2.2. ABNF Rules defined in other Parts of the Specification 305 The ABNF rules below are defined in other parts: 307 absolute-URI = 308 comment = 309 partial-URI = 310 product = 311 URI-reference = 313 2. Method 315 The Method token indicates the request method to be performed on the 316 target resource (Section 4.3 of [Part1]). The method is case- 317 sensitive. 319 Method = token 321 The list of methods allowed by a resource can be specified in an 322 Allow header field (Section 9.1). The status code of the response 323 always notifies the client whether a method is currently allowed on a 324 resource, since the set of allowed methods can change dynamically. 325 An origin server SHOULD respond with the status code 405 (Method Not 326 Allowed) if the method is known by the origin server but not allowed 327 for the resource, and 501 (Not Implemented) if the method is 328 unrecognized or not implemented by the origin server. The methods 329 GET and HEAD MUST be supported by all general-purpose servers. All 330 other methods are OPTIONAL; however, if the above methods are 331 implemented, they MUST be implemented with the same semantics as 332 those specified in Section 6. 334 2.1. Overview of Methods 336 The methods listed below are defined in Section 6. 338 +-------------+---------------+ 339 | Method Name | Defined in... | 340 +-------------+---------------+ 341 | OPTIONS | Section 6.2 | 342 | GET | Section 6.3 | 343 | HEAD | Section 6.4 | 344 | POST | Section 6.5 | 345 | PUT | Section 6.6 | 346 | DELETE | Section 6.7 | 347 | TRACE | Section 6.8 | 348 | CONNECT | Section 6.9 | 349 +-------------+---------------+ 351 Note that this list is not exhaustive -- it does not include request 352 methods defined in other specifications. 354 2.2. Method Registry 356 The HTTP Method Registry defines the name space for the Method token 357 in the Request line of an HTTP request. 359 Registrations MUST include the following fields: 361 o Method Name (see Section 2) 363 o Safe ("yes" or "no", see Section 6.1.1) 365 o Pointer to specification text 367 Values to be added to this name space are subject to IETF review 368 ([RFC5226], Section 4.1). 370 The registry itself is maintained at 371 . 373 2.2.1. Considerations for New Methods 375 When it is necessary to express new semantics for a HTTP request that 376 aren't specific to a single application or media type, and currently 377 defined methods are inadequate, it may be appropriate to register a 378 new method. 380 HTTP methods are generic; that is, they are potentially applicable to 381 any resource, not just one particular media type, "type" of resource, 382 or application. As such, it is preferred that new HTTP methods be 383 registered in a document that isn't specific to a single application, 384 so that this is clear. 386 Due to the parsing rules defined in Section 3.3 of [Part1], 387 definitions of HTTP methods cannot prohibit the presence of a 388 message-body on either the request or the response message (with 389 responses to HEAD requests being the single exception). Definitions 390 of new methods cannot change this rule, but they can specify that 391 only zero-length bodies (as opposed to absent bodies) are allowed. 393 New method definitions need to indicate whether they are safe 394 (Section 6.1.1), what semantics (if any) the request body has, and 395 whether they are idempotent (Section 6.1.2). They also need to state 396 whether they can be cached ([Part6]); in particular what conditions a 397 cache may store the response, and under what conditions such a stored 398 response may be used to satisfy a subsequent request. 400 3. Header Fields 402 Header fields are key value pairs that can be used to communicate 403 data about the message, its payload, the target resource, or about 404 the connection itself (i.e., control data). See Section 3.2 of 405 [Part1] for a general definition of their syntax. 407 3.1. Considerations for Creating Header Fields 409 New header fields are registered using the procedures described in 410 [RFC3864]. 412 The requirements for header field names are defined in Section 4.1 of 413 [RFC3864]. Authors of specifications defining new fields are advised 414 to keep the name as short as practical, and not to prefix them with 415 "X-" if they are to be registered (either immediately or in the 416 future). 418 New header field values typically have their syntax defined using 419 ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of 420 [Part1] as necessary, and are usually constrained to the range of 421 ASCII characters. Header fields needing a greater range of 422 characters can use an encoding such as the one defined in [RFC5987]. 424 Because commas (",") are used as a generic delimiter between field- 425 values, they need to be treated with care if they are allowed in the 426 field-value's payload. Typically, components that might contain a 427 comma are protected with double-quotes using the quoted-string ABNF 428 production (Section 3.2.3 of [Part1]). 430 For example, a textual date and a URI (either of which might contain 431 a comma) could be safely carried in field-values like these: 433 Example-URI-Field: "http://example.com/a.html,foo", 434 "http://without-a-comma.example.com/" 435 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 437 Many header fields use a format including (case-insensitively) named 438 parameters (for instance, Content-Type, defined in Section 6.8 of 439 [Part3]). Allowing both unquoted (token) and quoted (quoted-string) 440 syntax for the parameter value enables recipients to use existing 441 parser components. When allowing both forms, the meaning of a 442 parameter value ought to be independent of the syntax used for it 443 (for an example, see the notes on parameter handling for media types 444 in Section 2.3 of [Part3]). 446 Authors of specifications defining new header fields are advised to 447 consider documenting: 449 o Whether the field is a single value, or whether it can be a list 450 (delimited by commas; see Section 3.2 of [Part1]). 452 If it does not use the list syntax, document how to treat messages 453 where the header field occurs multiple times (a sensible default 454 would be to ignore the header field, but this might not always be 455 the right choice). 457 Note that intermediaries and software libraries might combine 458 multiple header field instances into a single one, despite the 459 header field not allowing this. A robust format enables 460 recipients to discover these situations (good example: "Content- 461 Type", as the comma can only appear inside quoted strings; bad 462 example: "Location", as a comma can occur inside a URI). 464 o Under what conditions the header field can be used; e.g., only in 465 responses or requests, in all messages, only on responses to a 466 particular request method. 468 o Whether it is appropriate to list the field-name in the Connection 469 header (i.e., if the header is to be hop-by-hop, see Section 8.1 470 of [Part1]). 472 o Under what conditions intermediaries are allowed to modify the 473 header field's value, insert or delete it. 475 o How the header might interact with caching (see [Part6]). 477 o Whether the header field is useful or allowable in trailers (see 478 Section 5.1.1 of [Part1]). 480 o Whether the header field should be preserved across redirects. 482 3.2. Request Header Fields 484 The request header fields allow the client to pass additional 485 information about the request, and about the client itself, to the 486 server. These fields act as request modifiers, with semantics 487 equivalent to the parameters on a programming language method 488 invocation. 490 +---------------------+------------------------+ 491 | Header Field Name | Defined in... | 492 +---------------------+------------------------+ 493 | Accept | Section 6.1 of [Part3] | 494 | Accept-Charset | Section 6.2 of [Part3] | 495 | Accept-Encoding | Section 6.3 of [Part3] | 496 | Accept-Language | Section 6.4 of [Part3] | 497 | Authorization | Section 4.1 of [Part7] | 498 | Expect | Section 9.3 | 499 | From | Section 9.4 | 500 | Host | Section 8.3 of [Part1] | 501 | If-Match | Section 3.1 of [Part4] | 502 | If-Modified-Since | Section 3.3 of [Part4] | 503 | If-None-Match | Section 3.2 of [Part4] | 504 | If-Range | Section 5.3 of [Part5] | 505 | If-Unmodified-Since | Section 3.4 of [Part4] | 506 | Max-Forwards | Section 9.6 | 507 | Proxy-Authorization | Section 4.3 of [Part7] | 508 | Range | Section 5.4 of [Part5] | 509 | Referer | Section 9.7 | 510 | TE | Section 8.4 of [Part1] | 511 | User-Agent | Section 9.10 | 512 +---------------------+------------------------+ 514 3.3. Response Header Fields 516 The response header fields allow the server to pass additional 517 information about the response which cannot be placed in the Status- 518 Line. These header fields give information about the server and 519 about further access to the target resource (Section 4.3 of [Part1]). 521 +--------------------+------------------------+ 522 | Header Field Name | Defined in... | 523 +--------------------+------------------------+ 524 | Accept-Ranges | Section 5.1 of [Part5] | 525 | Age | Section 3.1 of [Part6] | 526 | Allow | Section 9.1 | 527 | Date | Section 9.2 | 528 | ETag | Section 2.3 of [Part4] | 529 | Location | Section 9.5 | 530 | Proxy-Authenticate | Section 4.2 of [Part7] | 531 | Retry-After | Section 9.8 | 532 | Server | Section 9.9 | 533 | Vary | Section 3.5 of [Part6] | 534 | WWW-Authenticate | Section 4.4 of [Part7] | 535 +--------------------+------------------------+ 537 4. Status Code and Reason Phrase 539 The Status-Code element is a 3-digit integer result code of the 540 attempt to understand and satisfy the request. 542 The Reason-Phrase is intended to give a short textual description of 543 the Status-Code and is intended for a human user. The client does 544 not need to examine or display the Reason-Phrase. 546 Status-Code = 3DIGIT 547 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 549 HTTP status codes are extensible. HTTP applications are not required 550 to understand the meaning of all registered status codes, though such 551 understanding is obviously desirable. However, applications MUST 552 understand the class of any status code, as indicated by the first 553 digit, and treat any unrecognized response as being equivalent to the 554 x00 status code of that class, with the exception that an 555 unrecognized response MUST NOT be cached. For example, if an 556 unrecognized status code of 431 is received by the client, it can 557 safely assume that there was something wrong with its request and 558 treat the response as if it had received a 400 status code. In such 559 cases, user agents SHOULD present to the user the representation 560 enclosed with the response, since that representation is likely to 561 include human-readable information which will explain the unusual 562 status. 564 4.1. Overview of Status Codes 566 The status codes listed below are defined in Section 7 of this 567 specification, Section 4 of [Part4], Section 3 of [Part5], and 568 Section 3 of [Part7]. The reason phrases listed here are only 569 recommendations -- they can be replaced by local equivalents without 570 affecting the protocol. 572 +-------------+------------------------------+----------------------+ 573 | Status-Code | Reason-Phrase | Defined in... | 574 +-------------+------------------------------+----------------------+ 575 | 100 | Continue | Section 7.1.1 | 576 | 101 | Switching Protocols | Section 7.1.2 | 577 | 200 | OK | Section 7.2.1 | 578 | 201 | Created | Section 7.2.2 | 579 | 202 | Accepted | Section 7.2.3 | 580 | 203 | Non-Authoritative | Section 7.2.4 | 581 | | Information | | 582 | 204 | No Content | Section 7.2.5 | 583 | 205 | Reset Content | Section 7.2.6 | 584 | 206 | Partial Content | Section 3.1 of | 585 | | | [Part5] | 586 | 300 | Multiple Choices | Section 7.3.1 | 587 | 301 | Moved Permanently | Section 7.3.2 | 588 | 302 | Found | Section 7.3.3 | 589 | 303 | See Other | Section 7.3.4 | 590 | 304 | Not Modified | Section 4.1 of | 591 | | | [Part4] | 592 | 305 | Use Proxy | Section 7.3.6 | 593 | 307 | Temporary Redirect | Section 7.3.8 | 594 | 400 | Bad Request | Section 7.4.1 | 595 | 401 | Unauthorized | Section 3.1 of | 596 | | | [Part7] | 597 | 402 | Payment Required | Section 7.4.3 | 598 | 403 | Forbidden | Section 7.4.4 | 599 | 404 | Not Found | Section 7.4.5 | 600 | 405 | Method Not Allowed | Section 7.4.6 | 601 | 406 | Not Acceptable | Section 7.4.7 | 602 | 407 | Proxy Authentication | Section 3.2 of | 603 | | Required | [Part7] | 604 | 408 | Request Time-out | Section 7.4.9 | 605 | 409 | Conflict | Section 7.4.10 | 606 | 410 | Gone | Section 7.4.11 | 607 | 411 | Length Required | Section 7.4.12 | 608 | 412 | Precondition Failed | Section 4.2 of | 609 | | | [Part4] | 610 | 413 | Request Representation Too | Section 7.4.14 | 611 | | Large | | 612 | 414 | URI Too Long | Section 7.4.15 | 613 | 415 | Unsupported Media Type | Section 7.4.16 | 614 | 416 | Requested range not | Section 3.2 of | 615 | | satisfiable | [Part5] | 616 | 417 | Expectation Failed | Section 7.4.18 | 617 | 426 | Upgrade Required | Section 7.4.19 | 618 | 500 | Internal Server Error | Section 7.5.1 | 619 | 501 | Not Implemented | Section 7.5.2 | 620 | 502 | Bad Gateway | Section 7.5.3 | 621 | 503 | Service Unavailable | Section 7.5.4 | 622 | 504 | Gateway Time-out | Section 7.5.5 | 623 | 505 | HTTP Version not supported | Section 7.5.6 | 624 +-------------+------------------------------+----------------------+ 626 Note that this list is not exhaustive -- it does not include 627 extension status codes defined in other specifications. 629 4.2. Status Code Registry 631 The HTTP Status Code Registry defines the name space for the Status- 632 Code token in the Status-Line of an HTTP response. 634 Values to be added to this name space are subject to IETF review 635 ([RFC5226], Section 4.1). 637 The registry itself is maintained at 638 . 640 4.2.1. Considerations for New Status Codes 642 When it is necessary to express new semantics for a HTTP response 643 that aren't specific to a single application or media type, and 644 currently defined status codes are inadequate, a new status code can 645 be registered. 647 HTTP status codes are generic; that is, they are potentially 648 applicable to any resource, not just one particular media type, 649 "type" of resource, or application. As such, it is preferred that 650 new HTTP status codes be registered in a document that isn't specific 651 to a single application, so that this is clear. 653 Definitions of new HTTP status codes typically explain the request 654 conditions that produce a response containing the status code (e.g., 655 combinations of request headers and/or method(s)), along with any 656 interactions with response headers (e.g., those that are required, 657 those that modify the semantics of the response). 659 New HTTP status codes are required to fall under one of the 660 categories defined in Section 7. To allow existing parsers to 661 properly handle them, new status codes cannot disallow a response 662 body, although they can mandate a zero-length response body. They 663 can require the presence of one or more particular HTTP response 664 header(s). 666 Likewise, their definitions can specify that caches are allowed to 667 use heuristics to determine their freshness (see [Part6]; by default, 668 it is not allowed), and can define how to determine the resource 669 which they carry a representation for (see Section 5.1; by default, 670 it is anonymous). 672 5. Representation 674 Request and Response messages MAY transfer a representation if not 675 otherwise restricted by the request method or response status code. 676 A representation consists of metadata (representation header fields) 677 and data (representation body). When a complete or partial 678 representation is enclosed in an HTTP message, it is referred to as 679 the payload of the message. HTTP representations are defined in 680 [Part3]. 682 A representation body is only present in a message when a message- 683 body is present, as described in Section 3.3 of [Part1]. The 684 representation body is obtained from the message-body by decoding any 685 Transfer-Encoding that might have been applied to ensure safe and 686 proper transfer of the message. 688 5.1. Identifying the Resource Associated with a Representation 690 It is sometimes necessary to determine an identifier for the resource 691 associated with a representation. 693 An HTTP request representation, when present, is always associated 694 with an anonymous (i.e., unidentified) resource. 696 In the common case, an HTTP response is a representation of the 697 target resource (see Section 4.3 of [Part1]). However, this is not 698 always the case. To determine the URI of the resource a response is 699 associated with, the following rules are used (with the first 700 applicable one being selected): 702 1. If the response status code is 200 or 203 and the request method 703 was GET, the response payload is a representation of the target 704 resource. 706 2. If the response status code is 204, 206, or 304 and the request 707 method was GET or HEAD, the response payload is a partial 708 representation of the target resource. 710 3. If the response has a Content-Location header field, and that URI 711 is the same as the effective request URI, the response payload is 712 a representation of the target resource. 714 4. If the response has a Content-Location header field, and that URI 715 is not the same as the effective request URI, then the response 716 asserts that its payload is a representation of the resource 717 identified by the Content-Location URI. However, such an 718 assertion cannot be trusted unless it can be verified by other 719 means (not defined by HTTP). 721 5. Otherwise, the response is a representation of an anonymous 722 (i.e., unidentified) resource. 724 [[TODO-req-uri: The comparison function is going to have to be 725 defined somewhere, because we already need to compare URIs for things 726 like cache invalidation.]] 728 6. Method Definitions 730 The set of common request methods for HTTP/1.1 is defined below. 731 Although this set can be expanded, additional methods cannot be 732 assumed to share the same semantics for separately extended clients 733 and servers. 735 6.1. Safe and Idempotent Methods 737 6.1.1. Safe Methods 739 Implementors need to be aware that the software represents the user 740 in their interactions over the Internet, and need to allow the user 741 to be aware of any actions they take which might have an unexpected 742 significance to themselves or others. 744 In particular, the convention has been established that the GET, 745 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the 746 significance of taking an action other than retrieval. These request 747 methods ought to be considered "safe". This allows user agents to 748 represent other methods, such as POST, PUT and DELETE, in a special 749 way, so that the user is made aware of the fact that a possibly 750 unsafe action is being requested. 752 Naturally, it is not possible to ensure that the server does not 753 generate side-effects as a result of performing a GET request; in 754 fact, some dynamic resources consider that a feature. The important 755 distinction here is that the user did not request the side-effects, 756 so therefore cannot be held accountable for them. 758 6.1.2. Idempotent Methods 760 Request methods can also have the property of "idempotence" in that, 761 aside from error or expiration issues, the intended effect of 762 multiple identical requests is the same as for a single request. 763 PUT, DELETE, and all safe request methods are idempotent. It is 764 important to note that idempotence refers only to changes requested 765 by the client: a server is free to change its state due to multiple 766 requests for the purpose of tracking those requests, versioning of 767 results, etc. 769 6.2. OPTIONS 771 The OPTIONS method requests information about the communication 772 options available on the request/response chain identified by the 773 effective request URI. This method allows a client to determine the 774 options and/or requirements associated with a resource, or the 775 capabilities of a server, without implying a resource action or 776 initiating a resource retrieval. 778 Responses to the OPTIONS method are not cacheable. 780 If the OPTIONS request includes a message-body (as indicated by the 781 presence of Content-Length or Transfer-Encoding), then the media type 782 MUST be indicated by a Content-Type field. Although this 783 specification does not define any use for such a body, future 784 extensions to HTTP might use the OPTIONS body to make more detailed 785 queries on the server. 787 If the request-target is an asterisk ("*"), the OPTIONS request is 788 intended to apply to the server in general rather than to a specific 789 resource. Since a server's communication options typically depend on 790 the resource, the "*" request is only useful as a "ping" or "no-op" 791 type of method; it does nothing beyond allowing the client to test 792 the capabilities of the server. For example, this can be used to 793 test a proxy for HTTP/1.1 compliance (or lack thereof). 795 If the request-target is not an asterisk, the OPTIONS request applies 796 only to the options that are available when communicating with that 797 resource. 799 A 200 response SHOULD include any header fields that indicate 800 optional features implemented by the server and applicable to that 801 resource (e.g., Allow), possibly including extensions not defined by 802 this specification. The response body, if any, SHOULD also include 803 information about the communication options. The format for such a 804 body is not defined by this specification, but might be defined by 805 future extensions to HTTP. Content negotiation MAY be used to select 806 the appropriate response format. If no response body is included, 807 the response MUST include a Content-Length field with a field-value 808 of "0". 810 The Max-Forwards header field MAY be used to target a specific proxy 811 in the request chain (see Section 9.6). If no Max-Forwards field is 812 present in the request, then the forwarded request MUST NOT include a 813 Max-Forwards field. 815 6.3. GET 817 The GET method requests transfer of a current representation of the 818 target resource. 820 If the target resource is a data-producing process, it is the 821 produced data which shall be returned as the representation in the 822 response and not the source text of the process, unless that text 823 happens to be the output of the process. 825 The semantics of the GET method change to a "conditional GET" if the 826 request message includes an If-Modified-Since, If-Unmodified-Since, 827 If-Match, If-None-Match, or If-Range header field. A conditional GET 828 requests that the representation be transferred only under the 829 circumstances described by the conditional header field(s). The 830 conditional GET request is intended to reduce unnecessary network 831 usage by allowing cached representations to be refreshed without 832 requiring multiple requests or transferring data already held by the 833 client. 835 The semantics of the GET method change to a "partial GET" if the 836 request message includes a Range header field. A partial GET 837 requests that only part of the representation be transferred, as 838 described in Section 5.4 of [Part5]. The partial GET request is 839 intended to reduce unnecessary network usage by allowing partially- 840 retrieved representations to be completed without transferring data 841 already held by the client. 843 Bodies on GET requests have no defined semantics. Note that sending 844 a body on a GET request might cause some existing implementations to 845 reject the request. 847 The response to a GET request is cacheable and MAY be used to satisfy 848 subsequent GET and HEAD requests (see [Part6]). 850 See Section 11.2 for security considerations when used for forms. 852 6.4. HEAD 854 The HEAD method is identical to GET except that the server MUST NOT 855 return a message-body in the response. The metadata contained in the 856 HTTP header fields in response to a HEAD request SHOULD be identical 857 to the information sent in response to a GET request. This method 858 can be used for obtaining metadata about the representation implied 859 by the request without transferring the representation body. This 860 method is often used for testing hypertext links for validity, 861 accessibility, and recent modification. 863 The response to a HEAD request is cacheable and MAY be used to 864 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used 865 to update a previously cached representation from that resource; if 866 the new field values indicate that the cached representation differs 867 from the current representation (as would be indicated by a change in 868 Content-Length, ETag or Last-Modified), then the cache MUST treat the 869 cache entry as stale. 871 Bodies on HEAD requests have no defined semantics. Note that sending 872 a body on a HEAD request might cause some existing implementations to 873 reject the request. 875 6.5. POST 877 The POST method requests that the origin server accept the 878 representation enclosed in the request as data to be processed by the 879 target resource. POST is designed to allow a uniform method to cover 880 the following functions: 882 o Annotation of existing resources; 884 o Posting a message to a bulletin board, newsgroup, mailing list, or 885 similar group of articles; 887 o Providing a block of data, such as the result of submitting a 888 form, to a data-handling process; 890 o Extending a database through an append operation. 892 The actual function performed by the POST method is determined by the 893 server and is usually dependent on the effective request URI. 895 The action performed by the POST method might not result in a 896 resource that can be identified by a URI. In this case, either 200 897 (OK) or 204 (No Content) is the appropriate response status code, 898 depending on whether or not the response includes a representation 899 that describes the result. 901 If a resource has been created on the origin server, the response 902 SHOULD be 201 (Created) and contain a representation which describes 903 the status of the request and refers to the new resource, and a 904 Location header field (see Section 9.5). 906 Responses to POST requests are only cacheable when they include 907 explicit freshness information (see Section 2.3.1 of [Part6]). A 908 cached POST response with a Content-Location header field (see 909 Section 6.7 of [Part3]) whose value is the effective Request URI MAY 910 be used to satisfy subsequent GET and HEAD requests. 912 Note that POST caching is not widely implemented. However, the 303 913 (See Other) response can be used to direct the user agent to retrieve 914 a cacheable resource. 916 6.6. PUT 918 The PUT method requests that the state of the target resource be 919 created or replaced with the state defined by the representation 920 enclosed in the request message payload. A successful PUT of a given 921 representation would suggest that a subsequent GET on that same 922 target resource will result in an equivalent representation being 923 returned in a 200 (OK) response. However, there is no guarantee that 924 such a state change will be observable, since the target resource 925 might be acted upon by other user agents in parallel, or might be 926 subject to dynamic processing by the origin server, before any 927 subsequent GET is received. A successful response only implies that 928 the user agent's intent was achieved at the time of its processing by 929 the origin server. 931 If the target resource does not have a current representation and the 932 PUT successfully creates one, then the origin server MUST inform the 933 user agent by sending a 201 (Created) response. If the target 934 resource does have a current representation and that representation 935 is successfully modified in accordance with the state of the enclosed 936 representation, then either a 200 (OK) or 204 (No Content) response 937 SHOULD be sent to indicate successful completion of the request. 939 Unrecognized header fields SHOULD be ignored (i.e., not saved as part 940 of the resource state). 942 An origin server SHOULD verify that the PUT representation is 943 consistent with any constraints which the server has for the target 944 resource that cannot or will not be changed by the PUT. This is 945 particularly important when the origin server uses internal 946 configuration information related to the URI in order to set the 947 values for representation metadata on GET responses. When a PUT 948 representation is inconsistent with the target resource, the origin 949 server SHOULD either make them consistent, by transforming the 950 representation or changing the resource configuration, or respond 951 with an appropriate error message containing sufficient information 952 to explain why the representation is unsuitable. The 409 (Conflict) 953 or 415 (Unsupported Media Type) status codes are suggested, with the 954 latter being specific to constraints on Content-Type values. 956 For example, if the target resource is configured to always have a 957 Content-Type of "text/html" and the representation being PUT has a 958 Content-Type of "image/jpeg", then the origin server SHOULD do one 959 of: (a) reconfigure the target resource to reflect the new media 960 type; (b) transform the PUT representation to a format consistent 961 with that of the resource before saving it as the new resource state; 962 or, (c) reject the request with a 415 response indicating that the 963 target resource is limited to "text/html", perhaps including a link 964 to a different resource that would be a suitable target for the new 965 representation. 967 HTTP does not define exactly how a PUT method affects the state of an 968 origin server beyond what can be expressed by the intent of the user 969 agent request and the semantics of the origin server response. It 970 does not define what a resource might be, in any sense of that word, 971 beyond the interface provided via HTTP. It does not define how 972 resource state is "stored", nor how such storage might change as a 973 result of a change in resource state, nor how the origin server 974 translates resource state into representations. Generally speaking, 975 all implementation details behind the resource interface are 976 intentionally hidden by the server. 978 The fundamental difference between the POST and PUT methods is 979 highlighted by the different intent for the target resource. The 980 target resource in a POST request is intended to handle the enclosed 981 representation as a data-accepting process, such as for a gateway to 982 some other protocol or a document that accepts annotations. In 983 contrast, the target resource in a PUT request is intended to take 984 the enclosed representation as a new or replacement value. Hence, 985 the intent of PUT is idempotent and visible to intermediaries, even 986 though the exact effect is only known by the origin server. 988 Proper interpretation of a PUT request presumes that the user agent 989 knows what target resource is desired. A service that is intended to 990 select a proper URI on behalf of the client, after receiving a state- 991 changing request, SHOULD be implemented using the POST method rather 992 than PUT. If the origin server will not make the requested PUT state 993 change to the target resource and instead wishes to have it applied 994 to a different resource, such as when the resource has been moved to 995 a different URI, then the origin server MUST send a 301 (Moved 996 Permanently) response; the user agent MAY then make its own decision 997 regarding whether or not to redirect the request. 999 A PUT request applied to the target resource MAY have side-effects on 1000 other resources. For example, an article might have a URI for 1001 identifying "the current version" (a resource) which is separate from 1002 the URIs identifying each particular version (different resources 1003 that at one point shared the same state as the current version 1004 resource). A successful PUT request on "the current version" URI 1005 might therefore create a new version resource in addition to changing 1006 the state of the target resource, and might also cause links to be 1007 added between the related resources. 1009 An origin server SHOULD reject any PUT request that contains a 1010 Content-Range header field, since it might be misinterpreted as 1011 partial content (or might be partial content that is being mistakenly 1012 PUT as a full representation). Partial content updates are possible 1013 by targeting a separately identified resource with state that 1014 overlaps a portion of the larger resource, or by using a different 1015 method that has been specifically defined for partial updates (for 1016 example, the PATCH method defined in [RFC5789]). 1018 Responses to the PUT method are not cacheable. If a PUT request 1019 passes through a cache that has one or more stored responses for the 1020 effective request URI, those stored responses will be invalidated 1021 (see Section 2.5 of [Part6]). 1023 6.7. DELETE 1025 The DELETE method requests that the origin server delete the target 1026 resource. This method MAY be overridden by human intervention (or 1027 other means) on the origin server. The client cannot be guaranteed 1028 that the operation has been carried out, even if the status code 1029 returned from the origin server indicates that the action has been 1030 completed successfully. However, the server SHOULD NOT indicate 1031 success unless, at the time the response is given, it intends to 1032 delete the resource or move it to an inaccessible location. 1034 A successful response SHOULD be 200 (OK) if the response includes an 1035 representation describing the status, 202 (Accepted) if the action 1036 has not yet been enacted, or 204 (No Content) if the action has been 1037 enacted but the response does not include a representation. 1039 Bodies on DELETE requests have no defined semantics. Note that 1040 sending a body on a DELETE request might cause some existing 1041 implementations to reject the request. 1043 Responses to the DELETE method are not cacheable. If a DELETE 1044 request passes through a cache that has one or more stored responses 1045 for the effective request URI, those stored responses will be 1046 invalidated (see Section 2.5 of [Part6]). 1048 6.8. TRACE 1050 The TRACE method requests a remote, application-layer loop-back of 1051 the request message. The final recipient of the request SHOULD 1052 reflect the message received back to the client as the message-body 1053 of a 200 (OK) response. The final recipient is either the origin 1054 server or the first proxy to receive a Max-Forwards value of zero (0) 1055 in the request (see Section 9.6). A TRACE request MUST NOT include a 1056 message-body. 1058 TRACE allows the client to see what is being received at the other 1059 end of the request chain and use that data for testing or diagnostic 1060 information. The value of the Via header field (Section 8.8 of 1061 [Part1]) is of particular interest, since it acts as a trace of the 1062 request chain. Use of the Max-Forwards header field allows the 1063 client to limit the length of the request chain, which is useful for 1064 testing a chain of proxies forwarding messages in an infinite loop. 1066 If the request is valid, the response SHOULD have a Content-Type of 1067 "message/http" (see Section 9.3.1 of [Part1]) and contain a message- 1068 body that encloses a copy of the entire request message. Responses 1069 to the TRACE method are not cacheable. 1071 6.9. CONNECT 1073 The CONNECT method requests that the proxy establish a tunnel to the 1074 request-target and then restrict its behavior to blind forwarding of 1075 packets until the connection is closed. 1077 When using CONNECT, the request-target MUST use the authority form 1078 (Section 3.1.1.2 of [Part1]); i.e., the request-target consists of 1079 only the host name and port number of the tunnel destination, 1080 separated by a colon. For example, 1082 CONNECT server.example.com:80 HTTP/1.1 1083 Host: server.example.com:80 1085 Other HTTP mechanisms can be used normally with the CONNECT method -- 1086 except end-to-end protocol Upgrade requests, since the tunnel must be 1087 established first. 1089 For example, proxy authentication might be used to establish the 1090 authority to create a tunnel: 1092 CONNECT server.example.com:80 HTTP/1.1 1093 Host: server.example.com:80 1094 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1096 Bodies on CONNECT requests have no defined semantics. Note that 1097 sending a body on a CONNECT request might cause some existing 1098 implementations to reject the request. 1100 Like any other pipelined HTTP/1.1 request, data to be tunnel may be 1101 sent immediately after the blank line. The usual caveats also apply: 1102 data may be discarded if the eventual response is negative, and the 1103 connection may be reset with no response if more than one TCP segment 1104 is outstanding. 1106 6.9.1. Establishing a Tunnel with CONNECT 1108 Any successful (2xx) response to a CONNECT request indicates that the 1109 proxy has established a connection to the requested host and port, 1110 and has switched to tunneling the current connection to that server 1111 connection. 1113 It may be the case that the proxy itself can only reach the requested 1114 origin server through another proxy. In this case, the first proxy 1115 SHOULD make a CONNECT request of that next proxy, requesting a tunnel 1116 to the authority. A proxy MUST NOT respond with any 2xx status code 1117 unless it has either a direct or tunnel connection established to the 1118 authority. 1120 An origin server which receives a CONNECT request for itself MAY 1121 respond with a 2xx status code to indicate that a connection is 1122 established. 1124 If at any point either one of the peers gets disconnected, any 1125 outstanding data that came from that peer will be passed to the other 1126 one, and after that also the other connection will be terminated by 1127 the proxy. If there is outstanding data to that peer undelivered, 1128 that data will be discarded. 1130 7. Status Code Definitions 1132 The first digit of the Status-Code defines the class of response. 1133 The last two digits do not have any categorization role. There are 5 1134 values for the first digit: 1136 o 1xx: Informational - Request received, continuing process 1138 o 2xx: Success - The action was successfully received, understood, 1139 and accepted 1141 o 3xx: Redirection - Further action must be taken in order to 1142 complete the request 1144 o 4xx: Client Error - The request contains bad syntax or cannot be 1145 fulfilled 1147 o 5xx: Server Error - The server failed to fulfill an apparently 1148 valid request 1150 Each Status-Code is described below, including any metadata required 1151 in the response. 1153 7.1. Informational 1xx 1155 This class of status code indicates a provisional response, 1156 consisting only of the Status-Line and optional header fields, and is 1157 terminated by an empty line. There are no required header fields for 1158 this class of status code. Since HTTP/1.0 did not define any 1xx 1159 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 1160 client except under experimental conditions. 1162 A client MUST be prepared to accept one or more 1xx status responses 1163 prior to a regular response, even if the client does not expect a 100 1164 (Continue) status message. Unexpected 1xx status responses MAY be 1165 ignored by a user agent. 1167 Proxies MUST forward 1xx responses, unless the connection between the 1168 proxy and its client has been closed, or unless the proxy itself 1169 requested the generation of the 1xx response. (For example, if a 1170 proxy adds a "Expect: 100-continue" field when it forwards a request, 1171 then it need not forward the corresponding 100 (Continue) 1172 response(s).) 1174 7.1.1. 100 Continue 1176 The client SHOULD continue with its request. This interim response 1177 is used to inform the client that the initial part of the request has 1178 been received and has not yet been rejected by the server. The 1179 client SHOULD continue by sending the remainder of the request or, if 1180 the request has already been completed, ignore this response. The 1181 server MUST send a final response after the request has been 1182 completed. See Section 6.2.3 of [Part1] for detailed discussion of 1183 the use and handling of this status code. 1185 7.1.2. 101 Switching Protocols 1187 The server understands and is willing to comply with the client's 1188 request, via the Upgrade message header field (Section 8.7 of 1189 [Part1]), for a change in the application protocol being used on this 1190 connection. The server will switch protocols to those defined by the 1191 response's Upgrade header field immediately after the empty line 1192 which terminates the 101 response. 1194 The protocol SHOULD be switched only when it is advantageous to do 1195 so. For example, switching to a newer version of HTTP is 1196 advantageous over older versions, and switching to a real-time, 1197 synchronous protocol might be advantageous when delivering resources 1198 that use such features. 1200 7.2. Successful 2xx 1202 This class of status code indicates that the client's request was 1203 successfully received, understood, and accepted. 1205 7.2.1. 200 OK 1207 The request has succeeded. The payload returned with the response is 1208 dependent on the method used in the request, for example: 1210 GET a representation of the target resource is sent in the response; 1212 HEAD the same representation as GET, except without the message- 1213 body; 1215 POST a representation describing or containing the result of the 1216 action; 1218 TRACE a representation containing the request message as received by 1219 the end server. 1221 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1222 determine freshness for 200 responses. 1224 7.2.2. 201 Created 1226 The request has been fulfilled and has resulted in a new resource 1227 being created. The newly created resource can be referenced by the 1228 URI(s) returned in the payload of the response, with the most 1229 specific URI for the resource given by a Location header field. The 1230 response SHOULD include a payload containing a list of resource 1231 characteristics and location(s) from which the user or user agent can 1232 choose the one most appropriate. The payload format is specified by 1233 the media type given in the Content-Type header field. The origin 1234 server MUST create the resource before returning the 201 status code. 1235 If the action cannot be carried out immediately, the server SHOULD 1236 respond with 202 (Accepted) response instead. 1238 A 201 response MAY contain an ETag response header field indicating 1239 the current value of the entity-tag for the representation of the 1240 resource just created (see Section 2.3 of [Part4]). 1242 7.2.3. 202 Accepted 1244 The request has been accepted for processing, but the processing has 1245 not been completed. The request might or might not eventually be 1246 acted upon, as it might be disallowed when processing actually takes 1247 place. There is no facility for re-sending a status code from an 1248 asynchronous operation such as this. 1250 The 202 response is intentionally non-committal. Its purpose is to 1251 allow a server to accept a request for some other process (perhaps a 1252 batch-oriented process that is only run once per day) without 1253 requiring that the user agent's connection to the server persist 1254 until the process is completed. The representation returned with 1255 this response SHOULD include an indication of the request's current 1256 status and either a pointer to a status monitor or some estimate of 1257 when the user can expect the request to be fulfilled. 1259 7.2.4. 203 Non-Authoritative Information 1261 The representation in the response has been transformed or otherwise 1262 modified by a transforming proxy (Section 2.4 of [Part1]). Note that 1263 the behaviour of transforming intermediaries is controlled by the no- 1264 transform Cache-Control directive (Section 3.2 of [Part6]). 1266 This status code is only appropriate when the response status code 1267 would have been 200 (OK) otherwise. When the status code before 1268 transformation would have been different, the 214 Transformation 1269 Applied warn-code (Section 3.6 of [Part6]) is appropriate. 1271 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1272 determine freshness for 203 responses. 1274 7.2.5. 204 No Content 1276 The 204 (No Content) status code indicates that the server has 1277 successfully fulfilled the request and that there is no additional 1278 content to return in the response payload body. Metadata in the 1279 response header fields refer to the target resource and its current 1280 representation after the requested action. 1282 For example, if a 204 status code is received in response to a PUT 1283 request and the response contains an ETag header field, then the PUT 1284 was successful and the ETag field-value contains the entity-tag for 1285 the new representation of that target resource. 1287 The 204 response allows a server to indicate that the action has been 1288 successfully applied to the target resource while implying that the 1289 user agent SHOULD NOT traverse away from its current "document view" 1290 (if any). The server assumes that the user agent will provide some 1291 indication of the success to its user, in accord with its own 1292 interface, and apply any new or updated metadata in the response to 1293 the active representation. 1295 For example, a 204 status code is commonly used with document editing 1296 interfaces corresponding to a "save" action, such that the document 1297 being saved remains available to the user for editing. It is also 1298 frequently used with interfaces that expect automated data transfers 1299 to be prevalent, such as within distributed version control systems. 1301 The 204 response MUST NOT include a message-body, and thus is always 1302 terminated by the first empty line after the header fields. 1304 7.2.6. 205 Reset Content 1306 The server has fulfilled the request and the user agent SHOULD reset 1307 the document view which caused the request to be sent. This response 1308 is primarily intended to allow input for actions to take place via 1309 user input, followed by a clearing of the form in which the input is 1310 given so that the user can easily initiate another input action. 1312 The message-body included with the response MUST be empty. Note that 1313 receivers still need to parse the response according to the algorithm 1314 defined in Section 3.3 of [Part1]. 1316 7.2.7. 206 Partial Content 1318 The server has fulfilled the partial GET request for the resource and 1319 the enclosed payload is a partial representation as defined in 1320 Section 3.1 of [Part5]. 1322 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1323 determine freshness for 206 responses. 1325 7.3. Redirection 3xx 1327 This class of status code indicates that further action needs to be 1328 taken by the user agent in order to fulfill the request. If the 1329 required action involves a subsequent HTTP request, it MAY be carried 1330 out by the user agent without interaction with the user if and only 1331 if the method used in the second request is known to be "safe", as 1332 defined in Section 6.1.1. 1334 There are several types of redirects: 1336 1. Redirects of the request to another URI, either temporarily or 1337 permanently. The new URI is specified in the Location header 1338 field. In this specification, the status codes 301 (Moved 1339 Permanently), 302 (Found), and 307 (Temporary Redirect) fall 1340 under this category. 1342 2. Redirection to a new location that represents an indirect 1343 response to the request, such as the result of a POST operation 1344 to be retrieved with a subsequent GET request. This is status 1345 code 303 (See Other). 1347 3. Redirection offering a choice of matching resources for use by 1348 agent-driven content negotiation (Section 5.2 of [Part3]). This 1349 is status code 300 (Multiple Choices). 1351 4. Other kinds of redirection, such as to a cached result (status 1352 code 304 (Not Modified)). 1354 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently) 1355 and 302 (Found) were defined for the first type of redirect, and 1356 the second type did not exist at all ([RFC1945], Section 9.3). 1357 However it turned out that web forms using POST expected redirects 1358 to change the operation for the subsequent request to retrieval 1359 (GET). To address this use case, HTTP/1.1 introduced the second 1360 type of redirect with the status code 303 (See Other) ([RFC2068], 1361 Section 10.3.4). As user agents did not change their behavior to 1362 maintain backwards compatibility, the first revision of HTTP/1.1 1363 added yet another status code, 307 (Temporary Redirect), for which 1364 the backwards compatibility problems did not apply ([RFC2616], 1365 Section 10.3.8). Over 10 years later, most user agents still do 1366 method rewriting for status codes 301 and 302, therefore this 1367 specification makes that behavior compliant in case the original 1368 request was POST. 1370 Clients SHOULD detect and intervene in cyclical redirections (i.e., 1371 "infinite" redirection loops). 1373 Note: An earlier version of this specification recommended a 1374 maximum of five redirections ([RFC2068], Section 10.3). Content 1375 developers need to be aware that some clients might implement such 1376 a fixed limitation. 1378 7.3.1. 300 Multiple Choices 1380 The target resource has more than one representation, each with its 1381 own specific location, and agent-driven negotiation information 1382 (Section 5 of [Part3]) is being provided so that the user (or user 1383 agent) can select a preferred representation by redirecting its 1384 request to that location. 1386 Unless it was a HEAD request, the response SHOULD include a 1387 representation containing a list of representation metadata and 1388 location(s) from which the user or user agent can choose the one most 1389 appropriate. The data format is specified by the media type given in 1390 the Content-Type header field. Depending upon the format and the 1391 capabilities of the user agent, selection of the most appropriate 1392 choice MAY be performed automatically. However, this specification 1393 does not define any standard for such automatic selection. 1395 If the server has a preferred choice of representation, it SHOULD 1396 include the specific URI for that representation in the Location 1397 field; user agents MAY use the Location field value for automatic 1398 redirection. 1400 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1401 determine freshness for 300 responses. 1403 7.3.2. 301 Moved Permanently 1405 The target resource has been assigned a new permanent URI and any 1406 future references to this resource SHOULD use one of the returned 1407 URIs. Clients with link editing capabilities ought to automatically 1408 re-link references to the effective request URI to one or more of the 1409 new references returned by the server, where possible. 1411 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1412 determine freshness for 301 responses. 1414 The new permanent URI SHOULD be given by the Location field in the 1415 response. Unless the request method was HEAD, the representation of 1416 the response SHOULD contain a short hypertext note with a hyperlink 1417 to the new URI(s). 1419 If the 301 status code is received in response to a request method 1420 that is known to be "safe", as defined in Section 6.1.1, then the 1421 request MAY be automatically redirected by the user agent without 1422 confirmation. Otherwise, the user agent MUST NOT automatically 1423 redirect the request unless it can be confirmed by the user, since 1424 this might change the conditions under which the request was issued. 1426 Note: For historic reasons, user agents MAY change the request 1427 method from POST to GET for the subsequent request. If this 1428 behavior is undesired, status code 307 (Temporary Redirect) can be 1429 used instead. 1431 7.3.3. 302 Found 1433 The target resource resides temporarily under a different URI. Since 1434 the redirection might be altered on occasion, the client SHOULD 1435 continue to use the effective request URI for future requests. 1437 The temporary URI SHOULD be given by the Location field in the 1438 response. Unless the request method was HEAD, the representation of 1439 the response SHOULD contain a short hypertext note with a hyperlink 1440 to the new URI(s). 1442 If the 302 status code is received in response to a request method 1443 that is known to be "safe", as defined in Section 6.1.1, then the 1444 request MAY be automatically redirected by the user agent without 1445 confirmation. Otherwise, the user agent MUST NOT automatically 1446 redirect the request unless it can be confirmed by the user, since 1447 this might change the conditions under which the request was issued. 1449 Note: For historic reasons, user agents MAY change the request 1450 method from POST to GET for the subsequent request. If this 1451 behavior is undesired, status code 307 (Temporary Redirect) can be 1452 used instead. [[issue312: but see 1453 ]] 1455 7.3.4. 303 See Other 1457 The 303 status code indicates that the server is redirecting the user 1458 agent to a different resource, as indicated by a URI in the Location 1459 header field, that is intended to provide an indirect response to the 1460 original request. In order to satisfy the original request, a user 1461 agent SHOULD perform a retrieval request using the Location URI (a 1462 GET or HEAD request if using HTTP), which may itself be redirected 1463 further, and present the eventual result as an answer to the original 1464 request. Note that the new URI in the Location header field is not 1465 considered equivalent to the effective request URI. 1467 This status code is generally applicable to any HTTP method. It is 1468 primarily used to allow the output of a POST action to redirect the 1469 user agent to a selected resource, since doing so provides the 1470 information corresponding to the POST response in a form that can be 1471 separately identified, bookmarked, and cached independent of the 1472 original request. 1474 A 303 response to a GET request indicates that the requested resource 1475 does not have a representation of its own that can be transferred by 1476 the server over HTTP. The Location URI indicates a resource that is 1477 descriptive of the target resource, such that the follow-on 1478 representation might be useful to recipients without implying that it 1479 adequately represents the target resource. Note that answers to the 1480 questions of what can be represented, what representations are 1481 adequate, and what might be a useful description are outside the 1482 scope of HTTP and thus entirely determined by the URI owner(s). 1484 Except for responses to a HEAD request, the representation of a 303 1485 response SHOULD contain a short hypertext note with a hyperlink to 1486 the Location URI. 1488 7.3.5. 304 Not Modified 1490 The response to the request has not been modified since the 1491 conditions indicated by the client's conditional GET request, as 1492 defined in Section 4.1 of [Part4]. 1494 7.3.6. 305 Use Proxy 1496 The 305 status code was defined in a previous version of this 1497 specification (see Appendix A), and is now deprecated. 1499 7.3.7. 306 (Unused) 1501 The 306 status code was used in a previous version of the 1502 specification, is no longer used, and the code is reserved. 1504 7.3.8. 307 Temporary Redirect 1506 The target resource resides temporarily under a different URI. Since 1507 the redirection can change over time, the client SHOULD continue to 1508 use the effective request URI for future requests. 1510 The temporary URI SHOULD be given by the Location field in the 1511 response. Unless the request method was HEAD, the representation of 1512 the response SHOULD contain a short hypertext note with a hyperlink 1513 to the new URI(s), since many pre-HTTP/1.1 user agents do not 1514 understand the 307 status code. Therefore, the note SHOULD contain 1515 the information necessary for a user to repeat the original request 1516 on the new URI. 1518 If the 307 status code is received in response to a request method 1519 that is known to be "safe", as defined in Section 6.1.1, then the 1520 request MAY be automatically redirected by the user agent without 1521 confirmation. Otherwise, the user agent MUST NOT automatically 1522 redirect the request unless it can be confirmed by the user, since 1523 this might change the conditions under which the request was issued. 1525 7.4. Client Error 4xx 1527 The 4xx class of status code is intended for cases in which the 1528 client seems to have erred. Except when responding to a HEAD 1529 request, the server SHOULD include a representation containing an 1530 explanation of the error situation, and whether it is a temporary or 1531 permanent condition. These status codes are applicable to any 1532 request method. User agents SHOULD display any included 1533 representation to the user. 1535 If the client is sending data, a server implementation using TCP 1536 SHOULD be careful to ensure that the client acknowledges receipt of 1537 the packet(s) containing the response, before the server closes the 1538 input connection. If the client continues sending data to the server 1539 after the close, the server's TCP stack will send a reset packet to 1540 the client, which might erase the client's unacknowledged input 1541 buffers before they can be read and interpreted by the HTTP 1542 application. 1544 7.4.1. 400 Bad Request 1546 The server cannot or will not process the request, due to a client 1547 error (e.g., malformed syntax). 1549 7.4.2. 401 Unauthorized 1551 The request requires user authentication (see Section 3.1 of 1552 [Part7]). 1554 7.4.3. 402 Payment Required 1556 This code is reserved for future use. 1558 7.4.4. 403 Forbidden 1560 The server understood the request, but refuses to authorize it. 1561 Providing different user authentication credentials might be 1562 successful, but any credentials that were provided in the request are 1563 insufficient. The request SHOULD NOT be repeated with the same 1564 credentials. 1566 If the request method was not HEAD and the server wishes to make 1567 public why the request has not been fulfilled, it SHOULD describe the 1568 reason for the refusal in the representation. If the server does not 1569 wish to make this information available to the client, the status 1570 code 404 (Not Found) MAY be used instead. 1572 7.4.5. 404 Not Found 1574 The server has not found anything matching the effective request URI. 1575 No indication is given of whether the condition is temporary or 1576 permanent. The 410 (Gone) status code SHOULD be used if the server 1577 knows, through some internally configurable mechanism, that an old 1578 resource is permanently unavailable and has no forwarding address. 1579 This status code is commonly used when the server does not wish to 1580 reveal exactly why the request has been refused, or when no other 1581 response is applicable. 1583 7.4.6. 405 Method Not Allowed 1585 The method specified in the Request-Line is not allowed for the 1586 target resource. The response MUST include an Allow header field 1587 containing a list of valid methods for the requested resource. 1589 7.4.7. 406 Not Acceptable 1591 The resource identified by the request is only capable of generating 1592 response representations which have content characteristics not 1593 acceptable according to the Accept and Accept-* header fields sent in 1594 the request (see Section 6 of [Part3]). 1596 Unless it was a HEAD request, the response SHOULD include a 1597 representation containing a list of available representation 1598 characteristics and location(s) from which the user or user agent can 1599 choose the one most appropriate. The data format is specified by the 1600 media type given in the Content-Type header field. Depending upon 1601 the format and the capabilities of the user agent, selection of the 1602 most appropriate choice MAY be performed automatically. However, 1603 this specification does not define any standard for such automatic 1604 selection. 1606 Note: HTTP/1.1 servers are allowed to return responses which are 1607 not acceptable according to the accept header fields sent in the 1608 request. In some cases, this might even be preferable to sending 1609 a 406 response. User agents are encouraged to inspect the header 1610 fields of an incoming response to determine if it is acceptable. 1612 If the response could be unacceptable, a user agent SHOULD 1613 temporarily stop receipt of more data and query the user for a 1614 decision on further actions. 1616 7.4.8. 407 Proxy Authentication Required 1618 This code is similar to 401 (Unauthorized), but indicates that the 1619 client must first authenticate itself with the proxy (see Section 3.2 1620 of [Part7]). 1622 7.4.9. 408 Request Timeout 1624 The client did not produce a request within the time that the server 1625 was prepared to wait. The client MAY repeat the request without 1626 modifications at any later time. 1628 7.4.10. 409 Conflict 1630 The request could not be completed due to a conflict with the current 1631 state of the resource. This code is only allowed in situations where 1632 it is expected that the user might be able to resolve the conflict 1633 and resubmit the request. The response body SHOULD include enough 1634 information for the user to recognize the source of the conflict. 1635 Ideally, the response representation would include enough information 1636 for the user or user agent to fix the problem; however, that might 1637 not be possible and is not required. 1639 Conflicts are most likely to occur in response to a PUT request. For 1640 example, if versioning were being used and the representation being 1641 PUT included changes to a resource which conflict with those made by 1642 an earlier (third-party) request, the server might use the 409 1643 response to indicate that it can't complete the request. In this 1644 case, the response representation would likely contain a list of the 1645 differences between the two versions in a format defined by the 1646 response Content-Type. 1648 7.4.11. 410 Gone 1650 The target resource is no longer available at the server and no 1651 forwarding address is known. This condition is expected to be 1652 considered permanent. Clients with link editing capabilities SHOULD 1653 delete references to the effective request URI after user approval. 1654 If the server does not know, or has no facility to determine, whether 1655 or not the condition is permanent, the status code 404 (Not Found) 1656 SHOULD be used instead. 1658 The 410 response is primarily intended to assist the task of web 1659 maintenance by notifying the recipient that the resource is 1660 intentionally unavailable and that the server owners desire that 1661 remote links to that resource be removed. Such an event is common 1662 for limited-time, promotional services and for resources belonging to 1663 individuals no longer working at the server's site. It is not 1664 necessary to mark all permanently unavailable resources as "gone" or 1665 to keep the mark for any length of time -- that is left to the 1666 discretion of the server owner. 1668 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1669 determine freshness for 410 responses. 1671 7.4.12. 411 Length Required 1673 The server refuses to accept the request without a defined Content- 1674 Length. The client MAY repeat the request if it adds a valid 1675 Content-Length header field containing the length of the message-body 1676 in the request message. 1678 7.4.13. 412 Precondition Failed 1680 The precondition given in one or more of the header fields evaluated 1681 to false when it was tested on the server, as defined in Section 4.2 1682 of [Part4]. 1684 7.4.14. 413 Request Representation Too Large 1686 The server is refusing to process a request because the request 1687 representation is larger than the server is willing or able to 1688 process. The server MAY close the connection to prevent the client 1689 from continuing the request. 1691 If the condition is temporary, the server SHOULD include a Retry- 1692 After header field to indicate that it is temporary and after what 1693 time the client MAY try again. 1695 7.4.15. 414 URI Too Long 1697 The server is refusing to service the request because the effective 1698 request URI is longer than the server is willing to interpret. This 1699 rare condition is only likely to occur when a client has improperly 1700 converted a POST request to a GET request with long query 1701 information, when the client has descended into a URI "black hole" of 1702 redirection (e.g., a redirected URI prefix that points to a suffix of 1703 itself), or when the server is under attack by a client attempting to 1704 exploit security holes present in some servers using fixed-length 1705 buffers for reading or manipulating the effective request URI. 1707 7.4.16. 415 Unsupported Media Type 1709 The server is refusing to service the request because the request 1710 payload is in a format not supported by this request method on the 1711 target resource. 1713 7.4.17. 416 Requested Range Not Satisfiable 1715 The request included a Range header field (Section 5.4 of [Part5]) 1716 and none of the range-specifier values in this field overlap the 1717 current extent of the selected resource. See Section 3.2 of [Part5]. 1719 7.4.18. 417 Expectation Failed 1721 The expectation given in an Expect header field (see Section 9.3) 1722 could not be met by this server, or, if the server is a proxy, the 1723 server has unambiguous evidence that the request could not be met by 1724 the next-hop server. 1726 7.4.19. 426 Upgrade Required 1728 The request can not be completed without a prior protocol upgrade. 1729 This response MUST include an Upgrade header field (Section 8.7 of 1730 [Part1]) specifying the required protocols. 1732 Example: 1734 HTTP/1.1 426 Upgrade Required 1735 Upgrade: HTTP/2.0 1736 Connection: Upgrade 1738 The server SHOULD include a message body in the 426 response which 1739 indicates in human readable form the reason for the error and 1740 describes any alternative courses which may be available to the user. 1742 7.5. Server Error 5xx 1744 Response status codes beginning with the digit "5" indicate cases in 1745 which the server is aware that it has erred or is incapable of 1746 performing the request. Except when responding to a HEAD request, 1747 the server SHOULD include a representation containing an explanation 1748 of the error situation, and whether it is a temporary or permanent 1749 condition. User agents SHOULD display any included representation to 1750 the user. These response codes are applicable to any request method. 1752 7.5.1. 500 Internal Server Error 1754 The server encountered an unexpected condition which prevented it 1755 from fulfilling the request. 1757 7.5.2. 501 Not Implemented 1759 The server does not support the functionality required to fulfill the 1760 request. This is the appropriate response when the server does not 1761 recognize the request method and is not capable of supporting it for 1762 any resource. 1764 7.5.3. 502 Bad Gateway 1766 The server, while acting as a gateway or proxy, received an invalid 1767 response from the upstream server it accessed in attempting to 1768 fulfill the request. 1770 7.5.4. 503 Service Unavailable 1772 The server is currently unable or unwilling to handle the request due 1773 to reasons such as temporary overloading, maintenance of the server, 1774 or rate limiting of the client. 1776 The implication is that this is a temporary condition which will be 1777 alleviated after some delay. If known, the length of the delay MAY 1778 be indicated in a Retry-After header field (Section 9.8). If no 1779 Retry-After is given, the client SHOULD handle the response as it 1780 would for a 500 response. 1782 Note: The existence of the 503 status code does not imply that a 1783 server must use it when becoming overloaded. Some servers might 1784 wish to simply refuse the connection. 1786 7.5.5. 504 Gateway Timeout 1788 The server, while acting as a gateway or proxy, did not receive a 1789 timely response from the upstream server specified by the URI (e.g., 1790 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 1791 to access in attempting to complete the request. 1793 Note to implementors: some deployed proxies are known to return 1794 400 or 500 when DNS lookups time out. 1796 7.5.6. 505 HTTP Version Not Supported 1798 The server does not support, or refuses to support, the protocol 1799 version that was used in the request message. The server is 1800 indicating that it is unable or unwilling to complete the request 1801 using the same major version as the client, as described in Section 1802 2.6 of [Part1], other than with this error message. The response 1803 SHOULD contain a representation describing why that version is not 1804 supported and what other protocols are supported by that server. 1806 8. Date/Time Formats 1808 HTTP applications have historically allowed three different formats 1809 for date/time stamps. However, the preferred format is a fixed- 1810 length subset of that defined by [RFC1123]: 1812 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1814 The other formats are described here only for compatibility with 1815 obsolete implementations. 1817 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1818 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1820 HTTP/1.1 clients and servers that parse a date value MUST accept all 1821 three formats (for compatibility with HTTP/1.0), though they MUST 1822 only generate the RFC 1123 format for representing HTTP-date values 1823 in header fields. 1825 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1826 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1827 equal to UTC (Coordinated Universal Time). This is indicated in the 1828 first two formats by the inclusion of "GMT" as the three-letter 1829 abbreviation for time zone, and MUST be assumed when reading the 1830 asctime format. HTTP-date is case sensitive and MUST NOT include 1831 additional whitespace beyond that specifically included as SP in the 1832 grammar. 1834 HTTP-date = rfc1123-date / obs-date 1836 Preferred format: 1838 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1839 ; fixed length subset of the format defined in 1840 ; Section 5.2.14 of [RFC1123] 1842 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1843 / %x54.75.65 ; "Tue", case-sensitive 1844 / %x57.65.64 ; "Wed", case-sensitive 1845 / %x54.68.75 ; "Thu", case-sensitive 1846 / %x46.72.69 ; "Fri", case-sensitive 1847 / %x53.61.74 ; "Sat", case-sensitive 1848 / %x53.75.6E ; "Sun", case-sensitive 1850 date1 = day SP month SP year 1851 ; e.g., 02 Jun 1982 1853 day = 2DIGIT 1854 month = %x4A.61.6E ; "Jan", case-sensitive 1855 / %x46.65.62 ; "Feb", case-sensitive 1856 / %x4D.61.72 ; "Mar", case-sensitive 1857 / %x41.70.72 ; "Apr", case-sensitive 1858 / %x4D.61.79 ; "May", case-sensitive 1859 / %x4A.75.6E ; "Jun", case-sensitive 1860 / %x4A.75.6C ; "Jul", case-sensitive 1861 / %x41.75.67 ; "Aug", case-sensitive 1862 / %x53.65.70 ; "Sep", case-sensitive 1863 / %x4F.63.74 ; "Oct", case-sensitive 1864 / %x4E.6F.76 ; "Nov", case-sensitive 1865 / %x44.65.63 ; "Dec", case-sensitive 1866 year = 4DIGIT 1868 GMT = %x47.4D.54 ; "GMT", case-sensitive 1870 time-of-day = hour ":" minute ":" second 1871 ; 00:00:00 - 23:59:59 1873 hour = 2DIGIT 1874 minute = 2DIGIT 1875 second = 2DIGIT 1877 The semantics of day-name, day, month, year, and time-of-day are the 1878 same as those defined for the RFC 5322 constructs with the 1879 corresponding name ([RFC5322], Section 3.3). 1881 Obsolete formats: 1883 obs-date = rfc850-date / asctime-date 1884 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1885 date2 = day "-" month "-" 2DIGIT 1886 ; day-month-year (e.g., 02-Jun-82) 1888 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1889 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1890 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1891 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1892 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1893 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1894 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1896 asctime-date = day-name SP date3 SP time-of-day SP year 1897 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1898 ; month day (e.g., Jun 2) 1900 Note: Recipients of date values are encouraged to be robust in 1901 accepting date values that might have been sent by non-HTTP 1902 applications, as is sometimes the case when retrieving or posting 1903 messages via proxies/gateways to SMTP or NNTP. 1905 Note: HTTP requirements for the date/time stamp format apply only 1906 to their usage within the protocol stream. Clients and servers 1907 are not required to use these formats for user presentation, 1908 request logging, etc. 1910 9. Header Field Definitions 1912 This section defines the syntax and semantics of HTTP/1.1 header 1913 fields related to request and response semantics. 1915 9.1. Allow 1917 The "Allow" header field lists the set of methods advertised as 1918 supported by the target resource. The purpose of this field is 1919 strictly to inform the recipient of valid request methods associated 1920 with the resource. 1922 Allow = #Method 1924 Example of use: 1926 Allow: GET, HEAD, PUT 1928 The actual set of allowed methods is defined by the origin server at 1929 the time of each request. 1931 A proxy MUST NOT modify the Allow header field -- it does not need to 1932 understand all the methods specified in order to handle them 1933 according to the generic message handling rules. 1935 9.2. Date 1937 The "Date" header field represents the date and time at which the 1938 message was originated, having the same semantics as the Origination 1939 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 1940 field value is an HTTP-date, as defined in Section 8; it MUST be sent 1941 in rfc1123-date format. 1943 Date = HTTP-date 1945 An example is 1947 Date: Tue, 15 Nov 1994 08:12:31 GMT 1949 Origin servers MUST include a Date header field in all responses, 1950 except in these cases: 1952 1. If the response status code is 100 (Continue) or 101 (Switching 1953 Protocols), the response MAY include a Date header field, at the 1954 server's option. 1956 2. If the response status code conveys a server error, e.g., 500 1957 (Internal Server Error) or 503 (Service Unavailable), and it is 1958 inconvenient or impossible to generate a valid Date. 1960 3. If the server does not have a clock that can provide a reasonable 1961 approximation of the current time, its responses MUST NOT include 1962 a Date header field. 1964 A received message that does not have a Date header field MUST be 1965 assigned one by the recipient if the message will be cached by that 1966 recipient. 1968 Clients can use the Date header field as well; in order to keep 1969 request messages small, they are advised not to include it when it 1970 doesn't convey any useful information (as it is usually the case for 1971 requests that do not contain a payload). 1973 The HTTP-date sent in a Date header field SHOULD NOT represent a date 1974 and time subsequent to the generation of the message. It SHOULD 1975 represent the best available approximation of the date and time of 1976 message generation, unless the implementation has no means of 1977 generating a reasonably accurate date and time. In theory, the date 1978 ought to represent the moment just before the payload is generated. 1980 In practice, the date can be generated at any time during the message 1981 origination without affecting its semantic value. 1983 9.3. Expect 1985 The "Expect" header field is used to indicate that particular server 1986 behaviors are required by the client. 1988 Expect = 1#expectation 1990 expectation = "100-continue" / expectation-extension 1991 expectation-extension = token [ "=" ( token / quoted-string ) 1992 *expect-params ] 1993 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1995 A server that does not understand or is unable to comply with any of 1996 the expectation values in the Expect field of a request MUST respond 1997 with appropriate error status code. The server MUST respond with a 1998 417 (Expectation Failed) status code if any of the expectations 1999 cannot be met or, if there are other problems with the request, some 2000 other 4xx status code. 2002 This header field is defined with extensible syntax to allow for 2003 future extensions. If a server receives a request containing an 2004 Expect field that includes an expectation-extension that it does not 2005 support, it MUST respond with a 417 (Expectation Failed) status code. 2007 Comparison of expectation values is case-insensitive for unquoted 2008 tokens (including the 100-continue token), and is case-sensitive for 2009 quoted-string expectation-extensions. 2011 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 2012 return a 417 (Expectation Failed) status code if it receives a 2013 request with an expectation that it cannot meet. However, the Expect 2014 header field itself is end-to-end; it MUST be forwarded if the 2015 request is forwarded. 2017 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 2018 Expect header field. 2020 See Section 6.2.3 of [Part1] for the use of the 100 (Continue) status 2021 code. 2023 9.4. From 2025 The "From" header field, if given, SHOULD contain an Internet e-mail 2026 address for the human user who controls the requesting user agent. 2027 The address SHOULD be machine-usable, as defined by "mailbox" in 2028 Section 3.4 of [RFC5322]: 2030 From = mailbox 2032 mailbox = 2034 An example is: 2036 From: webmaster@example.org 2038 This header field MAY be used for logging purposes and as a means for 2039 identifying the source of invalid or unwanted requests. It SHOULD 2040 NOT be used as an insecure form of access protection. The 2041 interpretation of this field is that the request is being performed 2042 on behalf of the person given, who accepts responsibility for the 2043 method performed. In particular, robot agents SHOULD include this 2044 header field so that the person responsible for running the robot can 2045 be contacted if problems occur on the receiving end. 2047 The Internet e-mail address in this field MAY be separate from the 2048 Internet host which issued the request. For example, when a request 2049 is passed through a proxy the original issuer's address SHOULD be 2050 used. 2052 The client SHOULD NOT send the From header field without the user's 2053 approval, as it might conflict with the user's privacy interests or 2054 their site's security policy. It is strongly recommended that the 2055 user be able to disable, enable, and modify the value of this field 2056 at any time prior to a request. 2058 9.5. Location 2060 The "Location" header field is used to identify a newly created 2061 resource, or to redirect the recipient to a different location for 2062 completion of the request. 2064 For 201 (Created) responses, the Location is the URI of the new 2065 resource which was created by the request. For 3xx responses, the 2066 location SHOULD indicate the server's preferred URI for automatic 2067 redirection to the resource. 2069 The field value consists of a single URI-reference. When it has the 2070 form of a relative reference ([RFC3986], Section 4.2), the final 2071 value is computed by resolving it against the effective request URI 2072 ([RFC3986], Section 5). 2074 Location = URI-reference 2076 Examples are: 2078 Location: http://www.example.org/pub/WWW/People.html#tim 2080 Location: /index.html 2082 There are circumstances in which a fragment identifier in a Location 2083 URI would not be appropriate. For instance, when it appears in a 201 2084 Created response, where the Location header field specifies the URI 2085 for the entire created resource. 2087 Note: This specification does not define precedence rules for the 2088 case where the original URI, as navigated to by the user agent, 2089 and the Location header field value both contain fragment 2090 identifiers. Thus be aware that including fragment identifiers 2091 might inconvenience anyone relying on the semantics of the 2092 original URI's fragment identifier. 2094 Note: The Content-Location header field (Section 6.7 of [Part3]) 2095 differs from Location in that the Content-Location identifies the 2096 most specific resource corresponding to the enclosed 2097 representation. It is therefore possible for a response to 2098 contain header fields for both Location and Content-Location. 2100 9.6. Max-Forwards 2102 The "Max-Forwards" header field provides a mechanism with the TRACE 2103 (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number 2104 of times that the request is forwarded by proxies. This can be 2105 useful when the client is attempting to trace a request which appears 2106 to be failing or looping in mid-chain. 2108 Max-Forwards = 1*DIGIT 2110 The Max-Forwards value is a decimal integer indicating the remaining 2111 number of times this request message can be forwarded. 2113 Each recipient of a TRACE or OPTIONS request containing a Max- 2114 Forwards header field MUST check and update its value prior to 2115 forwarding the request. If the received value is zero (0), the 2116 recipient MUST NOT forward the request; instead, it MUST respond as 2117 the final recipient. If the received Max-Forwards value is greater 2118 than zero, then the forwarded message MUST contain an updated Max- 2119 Forwards field with a value decremented by one (1). 2121 The Max-Forwards header field MAY be ignored for all other request 2122 methods. 2124 9.7. Referer 2126 The "Referer" [sic] header field allows the client to specify the URI 2127 of the resource from which the effective request URI was obtained 2128 (the "referrer", although the header field is misspelled.). 2130 The Referer header field allows servers to generate lists of back- 2131 links to resources for interest, logging, optimized caching, etc. It 2132 also allows obsolete or mistyped links to be traced for maintenance. 2133 Some servers use Referer as a means of controlling where they allow 2134 links from (so-called "deep linking"), but legitimate requests do not 2135 always contain a Referer header field. 2137 If the effective request URI was obtained from a source that does not 2138 have its own URI (e.g., input from the user keyboard), the Referer 2139 field MUST either be sent with the value "about:blank", or not be 2140 sent at all. Note that this requirement does not apply to sources 2141 with non-HTTP URIs (e.g., FTP). 2143 Referer = absolute-URI / partial-URI 2145 Example: 2147 Referer: http://www.example.org/hypertext/Overview.html 2149 If the field value is a relative URI, it SHOULD be interpreted 2150 relative to the effective request URI. The URI MUST NOT include a 2151 fragment. See Section 11.2 for security considerations. 2153 9.8. Retry-After 2155 The header "Retry-After" field can be used with a 503 (Service 2156 Unavailable) response to indicate how long the service is expected to 2157 be unavailable to the requesting client. This field MAY also be used 2158 with any 3xx (Redirection) response to indicate the minimum time the 2159 user-agent is asked wait before issuing the redirected request. 2161 The value of this field can be either an HTTP-date or an integer 2162 number of seconds (in decimal) after the time of the response. 2164 Retry-After = HTTP-date / delta-seconds 2166 Time spans are non-negative decimal integers, representing time in 2167 seconds. 2169 delta-seconds = 1*DIGIT 2171 Two examples of its use are 2172 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2173 Retry-After: 120 2175 In the latter example, the delay is 2 minutes. 2177 9.9. Server 2179 The "Server" header field contains information about the software 2180 used by the origin server to handle the request. 2182 The field can contain multiple product tokens (Section 5.2 of 2183 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server 2184 and any significant subproducts. The product tokens are listed in 2185 order of their significance for identifying the application. 2187 Server = product *( RWS ( product / comment ) ) 2189 Example: 2191 Server: CERN/3.0 libwww/2.17 2193 If the response is being forwarded through a proxy, the proxy 2194 application MUST NOT modify the Server header field. Instead, it 2195 MUST include a Via field (as described in Section 8.8 of [Part1]). 2197 Note: Revealing the specific software version of the server might 2198 allow the server machine to become more vulnerable to attacks 2199 against software that is known to contain security holes. Server 2200 implementors are encouraged to make this field a configurable 2201 option. 2203 9.10. User-Agent 2205 The "User-Agent" header field contains information about the user 2206 agent originating the request. User agents SHOULD include this field 2207 with requests. 2209 Typically, it is used for statistical purposes, the tracing of 2210 protocol violations, and tailoring responses to avoid particular user 2211 agent limitations. 2213 The field can contain multiple product tokens (Section 5.2 of 2214 [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent 2215 and its significant subproducts. By convention, the product tokens 2216 are listed in order of their significance for identifying the 2217 application. 2219 Because this field is usually sent on every request a user agent 2220 makes, implementations are encouraged not to include needlessly fine- 2221 grained detail, and to limit (or even prohibit) the addition of 2222 subproducts by third parties. Overly long and detailed User-Agent 2223 field values make requests larger and can also be used to identify 2224 ("fingerprint") the user against their wishes. 2226 Likewise, implementations are encouraged not to use the product 2227 tokens of other implementations in order to declare compatibility 2228 with them, as this circumvents the purpose of the field. Finally, 2229 they are encouraged not to use comments to identify products; doing 2230 so makes the field value more difficult to parse. 2232 User-Agent = product *( RWS ( product / comment ) ) 2234 Example: 2236 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2238 10. IANA Considerations 2240 10.1. Method Registry 2242 The registration procedure for HTTP request methods is defined by 2243 Section 2.2 of this document. 2245 The HTTP Method Registry shall be created at 2246 and be populated with 2247 the registrations below: 2249 +---------+------+-------------+ 2250 | Method | Safe | Reference | 2251 +---------+------+-------------+ 2252 | CONNECT | no | Section 6.9 | 2253 | DELETE | no | Section 6.7 | 2254 | GET | yes | Section 6.3 | 2255 | HEAD | yes | Section 6.4 | 2256 | OPTIONS | yes | Section 6.2 | 2257 | POST | no | Section 6.5 | 2258 | PUT | no | Section 6.6 | 2259 | TRACE | yes | Section 6.8 | 2260 +---------+------+-------------+ 2262 10.2. Status Code Registry 2264 The registration procedure for HTTP Status Codes -- previously 2265 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2 2266 of this document. 2268 The HTTP Status Code Registry located at 2269 shall be updated 2270 with the registrations below: 2272 +-------+----------------------------------+----------------+ 2273 | Value | Description | Reference | 2274 +-------+----------------------------------+----------------+ 2275 | 100 | Continue | Section 7.1.1 | 2276 | 101 | Switching Protocols | Section 7.1.2 | 2277 | 200 | OK | Section 7.2.1 | 2278 | 201 | Created | Section 7.2.2 | 2279 | 202 | Accepted | Section 7.2.3 | 2280 | 203 | Non-Authoritative Information | Section 7.2.4 | 2281 | 204 | No Content | Section 7.2.5 | 2282 | 205 | Reset Content | Section 7.2.6 | 2283 | 300 | Multiple Choices | Section 7.3.1 | 2284 | 301 | Moved Permanently | Section 7.3.2 | 2285 | 302 | Found | Section 7.3.3 | 2286 | 303 | See Other | Section 7.3.4 | 2287 | 305 | Use Proxy | Section 7.3.6 | 2288 | 306 | (Unused) | Section 7.3.7 | 2289 | 307 | Temporary Redirect | Section 7.3.8 | 2290 | 400 | Bad Request | Section 7.4.1 | 2291 | 402 | Payment Required | Section 7.4.3 | 2292 | 403 | Forbidden | Section 7.4.4 | 2293 | 404 | Not Found | Section 7.4.5 | 2294 | 405 | Method Not Allowed | Section 7.4.6 | 2295 | 406 | Not Acceptable | Section 7.4.7 | 2296 | 407 | Proxy Authentication Required | Section 7.4.8 | 2297 | 408 | Request Timeout | Section 7.4.9 | 2298 | 409 | Conflict | Section 7.4.10 | 2299 | 410 | Gone | Section 7.4.11 | 2300 | 411 | Length Required | Section 7.4.12 | 2301 | 413 | Request Representation Too Large | Section 7.4.14 | 2302 | 414 | URI Too Long | Section 7.4.15 | 2303 | 415 | Unsupported Media Type | Section 7.4.16 | 2304 | 417 | Expectation Failed | Section 7.4.18 | 2305 | 426 | Upgrade Required | Section 7.4.19 | 2306 | 500 | Internal Server Error | Section 7.5.1 | 2307 | 501 | Not Implemented | Section 7.5.2 | 2308 | 502 | Bad Gateway | Section 7.5.3 | 2309 | 503 | Service Unavailable | Section 7.5.4 | 2310 | 504 | Gateway Timeout | Section 7.5.5 | 2311 | 505 | HTTP Version Not Supported | Section 7.5.6 | 2312 +-------+----------------------------------+----------------+ 2314 10.3. Header Field Registration 2316 The Message Header Field Registry located at shall be 2318 updated with the permanent registrations below (see [RFC3864]): 2320 +-------------------+----------+----------+--------------+ 2321 | Header Field Name | Protocol | Status | Reference | 2322 +-------------------+----------+----------+--------------+ 2323 | Allow | http | standard | Section 9.1 | 2324 | Date | http | standard | Section 9.2 | 2325 | Expect | http | standard | Section 9.3 | 2326 | From | http | standard | Section 9.4 | 2327 | Location | http | standard | Section 9.5 | 2328 | Max-Forwards | http | standard | Section 9.6 | 2329 | Referer | http | standard | Section 9.7 | 2330 | Retry-After | http | standard | Section 9.8 | 2331 | Server | http | standard | Section 9.9 | 2332 | User-Agent | http | standard | Section 9.10 | 2333 +-------------------+----------+----------+--------------+ 2335 The change controller is: "IETF (iesg@ietf.org) - Internet 2336 Engineering Task Force". 2338 11. Security Considerations 2340 This section is meant to inform application developers, information 2341 providers, and users of the security limitations in HTTP/1.1 as 2342 described by this document. The discussion does not include 2343 definitive solutions to the problems revealed, though it does make 2344 some suggestions for reducing security risks. 2346 11.1. Transfer of Sensitive Information 2348 Like any generic data transfer protocol, HTTP cannot regulate the 2349 content of the data that is transferred, nor is there any a priori 2350 method of determining the sensitivity of any particular piece of 2351 information within the context of any given request. Therefore, 2352 applications SHOULD supply as much control over this information as 2353 possible to the provider of that information. Four header fields are 2354 worth special mention in this context: Server, Via, Referer and From. 2356 Revealing the specific software version of the server might allow the 2357 server machine to become more vulnerable to attacks against software 2358 that is known to contain security holes. Implementors SHOULD make 2359 the Server header field a configurable option. 2361 Proxies which serve as a portal through a network firewall SHOULD 2362 take special precautions regarding the transfer of header information 2363 that identifies the hosts behind the firewall. In particular, they 2364 SHOULD remove, or replace with sanitized versions, any Via fields 2365 generated behind the firewall. 2367 The Referer header field allows reading patterns to be studied and 2368 reverse links drawn. Although it can be very useful, its power can 2369 be abused if user details are not separated from the information 2370 contained in the Referer. Even when the personal information has 2371 been removed, the Referer header field might indicate a private 2372 document's URI whose publication would be inappropriate. 2374 The information sent in the From field might conflict with the user's 2375 privacy interests or their site's security policy, and hence it 2376 SHOULD NOT be transmitted without the user being able to disable, 2377 enable, and modify the contents of the field. The user MUST be able 2378 to set the contents of this field within a user preference or 2379 application defaults configuration. 2381 We suggest, though do not require, that a convenient toggle interface 2382 be provided for the user to enable or disable the sending of From and 2383 Referer information. 2385 The User-Agent (Section 9.10) or Server (Section 9.9) header fields 2386 can sometimes be used to determine that a specific client or server 2387 have a particular security hole which might be exploited. 2388 Unfortunately, this same information is often used for other valuable 2389 purposes for which HTTP currently has no better mechanism. 2391 Furthermore, the User-Agent header field may contain enough entropy 2392 to be used, possibly in conjunction with other material, to uniquely 2393 identify the user. 2395 Some request methods, like TRACE (Section 6.8), expose information 2396 that was sent in request header fields within the body of their 2397 response. Clients SHOULD be careful with sensitive information, like 2398 Cookies, Authorization credentials, and other header fields that 2399 might be used to collect data from the client. 2401 11.2. Encoding Sensitive Information in URIs 2403 Because the source of a link might be private information or might 2404 reveal an otherwise private information source, it is strongly 2405 recommended that the user be able to select whether or not the 2406 Referer field is sent. For example, a browser client could have a 2407 toggle switch for browsing openly/anonymously, which would 2408 respectively enable/disable the sending of Referer and From 2409 information. 2411 Clients SHOULD NOT include a Referer header field in a (non-secure) 2412 HTTP request if the referring page was transferred with a secure 2413 protocol. 2415 Authors of services SHOULD NOT use GET-based forms for the submission 2416 of sensitive data because that data will be placed in the request- 2417 target. Many existing servers, proxies, and user agents log or 2418 display the request-target in places where it might be visible to 2419 third parties. Such services can use POST-based form submission 2420 instead. 2422 11.3. Location Headers and Spoofing 2424 If a single server supports multiple organizations that do not trust 2425 one another, then it MUST check the values of Location and Content- 2426 Location header fields in responses that are generated under control 2427 of said organizations to make sure that they do not attempt to 2428 invalidate resources over which they have no authority. 2430 11.4. Security Considerations for CONNECT 2432 Since tunneled data is opaque to the proxy, there are additional 2433 risks to tunneling to other well-known or reserved ports. A HTTP 2434 client CONNECTing to port 25 could relay spam via SMTP, for example. 2435 As such, proxies SHOULD restrict CONNECT access to a small number of 2436 known ports. 2438 12. Acknowledgments 2440 See Section 11 of [Part1]. 2442 13. References 2444 13.1. Normative References 2446 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2447 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2448 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 2449 and Message Parsing", draft-ietf-httpbis-p1-messaging-17 2450 (work in progress), October 2011. 2452 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2453 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2454 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2455 and Content Negotiation", draft-ietf-httpbis-p3-payload-17 2456 (work in progress), October 2011. 2458 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2459 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2460 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 2461 Requests", draft-ietf-httpbis-p4-conditional-17 (work in 2462 progress), October 2011. 2464 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2465 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2466 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2467 Partial Responses", draft-ietf-httpbis-p5-range-17 (work 2468 in progress), October 2011. 2470 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2471 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2472 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2473 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in 2474 progress), October 2011. 2476 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2477 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2478 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 2479 draft-ietf-httpbis-p7-auth-17 (work in progress), 2480 October 2011. 2482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2483 Requirement Levels", BCP 14, RFC 2119, March 1997. 2485 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2486 Resource Identifier (URI): Generic Syntax", STD 66, 2487 RFC 3986, January 2005. 2489 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2490 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2492 13.2. Informative References 2494 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2495 and Support", STD 3, RFC 1123, October 1989. 2497 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2498 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2500 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2501 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2502 RFC 2068, January 1997. 2504 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2505 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2506 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2508 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 2509 HTTP/1.1", RFC 2817, May 2000. 2511 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2512 Procedures for Message Header Fields", BCP 90, RFC 3864, 2513 September 2004. 2515 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2516 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2517 May 2008. 2519 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2520 October 2008. 2522 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 2523 RFC 5789, March 2010. 2525 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2526 Hypertext Transfer Protocol (HTTP) Header Field 2527 Parameters", RFC 5987, August 2010. 2529 Appendix A. Changes from RFC 2616 2531 This document takes over the Status Code Registry, previously defined 2532 in Section 7.1 of [RFC2817]. (Section 4.2) 2534 Clarify definition of POST. (Section 6.5) 2536 Remove requirement to handle all Content-* header fields; ban use of 2537 Content-Range with PUT. (Section 6.6) 2539 Take over definition of CONNECT method from [RFC2817]. (Section 6.9) 2541 Broadened the definition of 203 (Non-Authoritative Information) to 2542 include cases of payload transformations as well. (Section 7.2.4) 2544 Failed to consider that there are many other request methods that are 2545 safe to automatically redirect, and further that the user agent is 2546 able to make that determination based on the request method 2547 semantics. Furthermore, allow user agents to rewrite the method from 2548 POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and 2549 7.3.8) 2551 Deprecate 305 Use Proxy status code, because user agents did not 2552 implement it. It used to indicate that the target resource must be 2553 accessed through the proxy given by the Location field. The Location 2554 field gave the URI of the proxy. The recipient was expected to 2555 repeat this single request via the proxy. (Section 7.3.6) 2556 Define status 426 (Upgrade Required) (this was incorporated from 2557 [RFC2817]). (Section 7.4.19) 2559 Change ABNF productions for header fields to only define the field 2560 value. (Section 9) 2562 Reclassify "Allow" as response header field, removing the option to 2563 specify it in a PUT request. Relax the server requirement on the 2564 contents of the Allow header field and remove requirement on clients 2565 to always trust the header field value. (Section 9.1) 2567 Correct syntax of Location header field to allow URI references 2568 (including relative references and fragments), as referred symbol 2569 "absoluteURI" wasn't what was expected, and add some clarifications 2570 as to when use of fragments would not be appropriate. (Section 9.5) 2572 Restrict Max-Forwards header field to OPTIONS and TRACE (previously, 2573 extension methods could have used it as well). (Section 9.6) 2575 Allow Referer field value of "about:blank" as alternative to not 2576 specifying it. (Section 9.7) 2578 In the description of the Server header field, the Via field was 2579 described as a SHOULD. The requirement was and is stated correctly 2580 in the description of the Via header field in Section 8.8 of [Part1]. 2581 (Section 9.9) 2583 Appendix B. Collected ABNF 2585 Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2587 Date = HTTP-date 2589 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2591 From = mailbox 2593 GMT = %x47.4D.54 ; GMT 2595 HTTP-date = rfc1123-date / obs-date 2597 Location = URI-reference 2599 Max-Forwards = 1*DIGIT 2600 Method = token 2602 OWS = 2603 RWS = 2604 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 2605 Referer = absolute-URI / partial-URI 2606 Retry-After = HTTP-date / delta-seconds 2608 Server = product *( RWS ( product / comment ) ) 2609 Status-Code = 3DIGIT 2611 URI-reference = 2612 User-Agent = product *( RWS ( product / comment ) ) 2614 absolute-URI = 2615 asctime-date = day-name SP date3 SP time-of-day SP year 2617 comment = 2619 date1 = day SP month SP year 2620 date2 = day "-" month "-" 2DIGIT 2621 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 2622 day = 2DIGIT 2623 day-name = %x4D.6F.6E ; Mon 2624 / %x54.75.65 ; Tue 2625 / %x57.65.64 ; Wed 2626 / %x54.68.75 ; Thu 2627 / %x46.72.69 ; Fri 2628 / %x53.61.74 ; Sat 2629 / %x53.75.6E ; Sun 2630 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 2631 / %x54.75.65.73.64.61.79 ; Tuesday 2632 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 2633 / %x54.68.75.72.73.64.61.79 ; Thursday 2634 / %x46.72.69.64.61.79 ; Friday 2635 / %x53.61.74.75.72.64.61.79 ; Saturday 2636 / %x53.75.6E.64.61.79 ; Sunday 2637 delta-seconds = 1*DIGIT 2639 expect-params = ";" token [ "=" ( token / quoted-string ) ] 2640 expectation = "100-continue" / expectation-extension 2641 expectation-extension = token [ "=" ( token / quoted-string ) 2642 *expect-params ] 2644 hour = 2DIGIT 2646 mailbox = 2647 minute = 2DIGIT 2648 month = %x4A.61.6E ; Jan 2649 / %x46.65.62 ; Feb 2650 / %x4D.61.72 ; Mar 2651 / %x41.70.72 ; Apr 2652 / %x4D.61.79 ; May 2653 / %x4A.75.6E ; Jun 2654 / %x4A.75.6C ; Jul 2655 / %x41.75.67 ; Aug 2656 / %x53.65.70 ; Sep 2657 / %x4F.63.74 ; Oct 2658 / %x4E.6F.76 ; Nov 2659 / %x44.65.63 ; Dec 2661 obs-date = rfc850-date / asctime-date 2662 obs-text = 2664 partial-URI = 2665 product = 2667 quoted-string = 2669 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 2670 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 2672 second = 2DIGIT 2674 time-of-day = hour ":" minute ":" second 2675 token = 2677 year = 4DIGIT 2679 ABNF diagnostics: 2681 ; Allow defined but not used 2682 ; Date defined but not used 2683 ; Expect defined but not used 2684 ; From defined but not used 2685 ; Location defined but not used 2686 ; Max-Forwards defined but not used 2687 ; Reason-Phrase defined but not used 2688 ; Referer defined but not used 2689 ; Retry-After defined but not used 2690 ; Server defined but not used 2691 ; Status-Code defined but not used 2692 ; User-Agent defined but not used 2694 Appendix C. Change Log (to be removed by RFC Editor before publication) 2696 C.1. Since RFC 2616 2698 Extracted relevant partitions from [RFC2616]. 2700 C.2. Since draft-ietf-httpbis-p2-semantics-00 2702 Closed issues: 2704 o : "Via is a MUST" 2705 () 2707 o : "Fragments 2708 allowed in Location" 2709 () 2711 o : "Safe Methods 2712 vs Redirection" () 2714 o : "Revise 2715 description of the POST method" 2716 () 2718 o : "Normative and 2719 Informative references" 2721 o : "RFC2606 2722 Compliance" 2724 o : "Informative 2725 references" 2727 o : "Redundant 2728 cross-references" 2730 Other changes: 2732 o Move definitions of 304 and 412 condition codes to [Part4] 2734 C.3. Since draft-ietf-httpbis-p2-semantics-01 2736 Closed issues: 2738 o : "PUT side 2739 effects" 2741 o : "Duplicate Host 2742 header requirements" 2744 Ongoing work on ABNF conversion 2745 (): 2747 o Move "Product Tokens" section (back) into Part 1, as "token" is 2748 used in the definition of the Upgrade header field. 2750 o Add explicit references to BNF syntax and rules imported from 2751 other parts of the specification. 2753 o Copy definition of delta-seconds from Part6 instead of referencing 2754 it. 2756 C.4. Since draft-ietf-httpbis-p2-semantics-02 2758 Closed issues: 2760 o : "Requiring 2761 Allow in 405 responses" 2763 o : "Status Code 2764 Registry" 2766 o : "Redirection 2767 vs. Location" 2769 o : "Cacheability 2770 of 303 response" 2772 o : "305 Use Proxy" 2774 o : 2775 "Classification for Allow header" 2777 o : "PUT - 'store 2778 under' vs 'store at'" 2780 Ongoing work on IANA Message Header Field Registration 2781 (): 2783 o Reference RFC 3984, and update header field registrations for 2784 headers defined in this document. 2786 Ongoing work on ABNF conversion 2787 (): 2789 o Replace string literals when the string really is case-sensitive 2790 (method). 2792 C.5. Since draft-ietf-httpbis-p2-semantics-03 2794 Closed issues: 2796 o : "OPTIONS 2797 request bodies" 2799 o : "Description 2800 of CONNECT should refer to RFC2817" 2802 o : "Location 2803 Content-Location reference request/response mixup" 2805 Ongoing work on Method Registry 2806 (): 2808 o Added initial proposal for registration process, plus initial 2809 content (non-HTTP/1.1 methods to be added by a separate 2810 specification). 2812 C.6. Since draft-ietf-httpbis-p2-semantics-04 2814 Closed issues: 2816 o : "Content-*" 2818 o : "RFC 2822 is 2819 updated by RFC 5322" 2821 Ongoing work on ABNF conversion 2822 (): 2824 o Use "/" instead of "|" for alternatives. 2826 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2827 whitespace ("OWS") and required whitespace ("RWS"). 2829 o Rewrite ABNFs to spell out whitespace rules, factor out header 2830 field value format definitions. 2832 C.7. Since draft-ietf-httpbis-p2-semantics-05 2834 Closed issues: 2836 o : "Reason-Phrase 2837 BNF" 2839 Final work on ABNF conversion 2840 (): 2842 o Add appendix containing collected and expanded ABNF, reorganize 2843 ABNF introduction. 2845 C.8. Since draft-ietf-httpbis-p2-semantics-06 2847 Closed issues: 2849 o : "Clarify when 2850 Referer is sent" 2852 o : "status codes 2853 vs methods" 2855 o : "Do not 2856 require "updates" relation for specs that register status codes or 2857 method names" 2859 C.9. Since draft-ietf-httpbis-p2-semantics-07 2861 Closed issues: 2863 o : "Idempotency" 2865 o : "TRACE security 2866 considerations" 2868 o : "Clarify rules 2869 for determining what entities a response carries" 2871 o : "update note 2872 citing RFC 1945 and 2068" 2874 o : "update note 2875 about redirect limit" 2877 o : "Location 2878 header ABNF should use 'URI'" 2880 o : "fragments in 2881 Location vs status 303" 2883 o : "move IANA 2884 registrations for optional status codes" 2886 Partly resolved issues: 2888 o : "Are OPTIONS 2889 and TRACE safe?" 2891 C.10. Since draft-ietf-httpbis-p2-semantics-08 2893 Closed issues: 2895 o : "Safe Methods 2896 vs Redirection" (we missed the introduction to the 3xx status 2897 codes when fixing this previously) 2899 C.11. Since draft-ietf-httpbis-p2-semantics-09 2901 Closed issues: 2903 o : "Fragment 2904 combination / precedence during redirects" 2906 Partly resolved issues: 2908 o : "Location 2909 header payload handling" 2911 o : "Term for the 2912 requested resource's URI" 2914 C.12. Since draft-ietf-httpbis-p2-semantics-10 2916 Closed issues: 2918 o : "Clarify 2919 'Requested Variant'" 2921 o : "Clarify 2922 entity / representation / variant terminology" 2924 o : "Methods and 2925 Caching" 2927 o : "OPTIONS vs 2928 Max-Forwards" 2930 o : "Status codes 2931 and caching" 2933 o : "consider 2934 removing the 'changes from 2068' sections" 2936 C.13. Since draft-ietf-httpbis-p2-semantics-11 2938 Closed issues: 2940 o : 2941 "Considerations for new status codes" 2943 o : 2944 "Considerations for new methods" 2946 o : "User-Agent 2947 guidelines" (relating to the 'User-Agent' header field) 2949 C.14. Since draft-ietf-httpbis-p2-semantics-12 2951 Closed issues: 2953 o : "Fragment 2954 combination / precedence during redirects" (added warning about 2955 having a fragid on the redirect may cause inconvenience in some 2956 cases) 2958 o : "Content-* vs. 2959 PUT" 2961 o : "205 Bodies" 2963 o : "Understanding 2964 Content-* on non-PUT requests" 2966 o : "Content-*" 2968 o : "Header type 2969 defaulting" 2971 o : "PUT - 'store 2972 under' vs 'store at'" 2974 o : "duplicate 2975 ABNF for Reason-Phrase" 2977 o : "Note special 2978 status of Content-* prefix in header registration procedures" 2980 o : "Max-Forwards 2981 vs extension methods" 2983 o : "What is the 2984 value space of HTTP status codes?" (actually fixed in 2985 draft-ietf-httpbis-p2-semantics-11) 2987 o : "Header 2988 Classification" 2990 o : "PUT side 2991 effect: invalidation or just stale?" 2993 o : "proxies not 2994 supporting certain methods" 2996 o : "Migrate 2997 CONNECT from RFC2817 to p2" 2999 o : "Migrate 3000 Upgrade details from RFC2817" 3002 o : "clarify PUT 3003 semantics'" 3005 o : "duplicate 3006 ABNF for 'Method'" 3008 o : "untangle 3009 ABNFs for header fields" 3011 C.15. Since draft-ietf-httpbis-p2-semantics-13 3013 Closed issues: 3015 o : "untangle 3016 ABNFs for header fields" 3018 o : "message-body 3019 in CONNECT request" 3021 C.16. Since draft-ietf-httpbis-p2-semantics-14 3023 Closed issues: 3025 o : "Clarify 3026 status code for rate limiting" 3028 o : "clarify 403 3029 forbidden" 3031 o : "Clarify 203 3032 Non-Authoritative Information" 3034 o : "update 3035 default reason phrase for 413" 3037 C.17. Since draft-ietf-httpbis-p2-semantics-15 3039 Closed issues: 3041 o : "Strength of 3042 requirements on Accept re: 406" 3044 o : "400 response 3045 isn't generic" 3047 C.18. Since draft-ietf-httpbis-p2-semantics-16 3049 Closed issues: 3051 o : "Redirects and 3052 non-GET methods" 3054 o : "Document 3055 HTTP's error-handling philosophy" 3057 o : 3058 "Considerations for new headers" 3060 o : "clarify 303 3061 redirect on HEAD" 3063 Index 3065 1 3066 100 Continue (status code) 26 3067 101 Switching Protocols (status code) 26 3069 2 3070 200 OK (status code) 27 3071 201 Created (status code) 27 3072 202 Accepted (status code) 28 3073 203 Non-Authoritative Information (status code) 28 3074 204 No Content (status code) 28 3075 205 Reset Content (status code) 29 3076 206 Partial Content (status code) 29 3078 3 3079 300 Multiple Choices (status code) 30 3080 301 Moved Permanently (status code) 31 3081 302 Found (status code) 32 3082 303 See Other (status code) 32 3083 304 Not Modified (status code) 33 3084 305 Use Proxy (status code) 33 3085 306 (Unused) (status code) 33 3086 307 Temporary Redirect (status code) 33 3088 4 3089 400 Bad Request (status code) 34 3090 401 Unauthorized (status code) 34 3091 402 Payment Required (status code) 34 3092 403 Forbidden (status code) 34 3093 404 Not Found (status code) 35 3094 405 Method Not Allowed (status code) 35 3095 406 Not Acceptable (status code) 35 3096 407 Proxy Authentication Required (status code) 35 3097 408 Request Timeout (status code) 36 3098 409 Conflict (status code) 36 3099 410 Gone (status code) 36 3100 411 Length Required (status code) 37 3101 412 Precondition Failed (status code) 37 3102 413 Request Representation Too Large (status code) 37 3103 414 URI Too Long (status code) 37 3104 415 Unsupported Media Type (status code) 37 3105 416 Requested Range Not Satisfiable (status code) 38 3106 417 Expectation Failed (status code) 38 3107 426 Upgrade Required (status code) 38 3109 5 3110 500 Internal Server Error (status code) 38 3111 501 Not Implemented (status code) 39 3112 502 Bad Gateway (status code) 39 3113 503 Service Unavailable (status code) 39 3114 504 Gateway Timeout (status code) 39 3115 505 HTTP Version Not Supported (status code) 39 3117 A 3118 Allow header field 42 3120 C 3121 CONNECT method 24 3123 D 3124 Date header field 43 3125 DELETE method 23 3127 E 3128 Expect header field 44 3130 F 3131 From header field 44 3133 G 3134 GET method 19 3135 Grammar 3136 Allow 42 3137 asctime-date 42 3138 Date 43 3139 date1 41 3140 day 41 3141 day-name 41 3142 day-name-l 41 3143 delta-seconds 47 3144 Expect 44 3145 expect-params 44 3146 expectation 44 3147 expectation-extension 44 3148 extension-code 12 3149 From 45 3150 GMT 41 3151 hour 41 3152 HTTP-date 40 3153 Location 45 3154 Max-Forwards 46 3155 Method 7 3156 minute 41 3157 month 41 3158 obs-date 41 3159 Reason-Phrase 12 3160 Referer 47 3161 Retry-After 47 3162 rfc850-date 42 3163 rfc1123-date 41 3164 second 41 3165 Server 48 3166 Status-Code 12 3167 time-of-day 41 3168 User-Agent 49 3169 year 41 3171 H 3172 HEAD method 19 3173 Header Fields 3174 Allow 42 3175 Date 43 3176 Expect 44 3177 From 44 3178 Location 45 3179 Max-Forwards 46 3180 Referer 47 3181 Retry-After 47 3182 Server 48 3183 User-Agent 48 3185 I 3186 Idempotent Methods 17 3188 L 3189 Location header field 45 3191 M 3192 Max-Forwards header field 46 3193 Methods 3194 CONNECT 24 3195 DELETE 23 3196 GET 19 3197 HEAD 19 3198 OPTIONS 18 3199 POST 20 3200 PUT 21 3201 TRACE 23 3203 O 3204 OPTIONS method 18 3206 P 3207 POST method 20 3208 PUT method 21 3210 R 3211 Referer header field 47 3212 Retry-After header field 47 3214 S 3215 Safe Methods 17 3216 Server header field 48 3217 Status Codes 3218 100 Continue 26 3219 101 Switching Protocols 26 3220 200 OK 27 3221 201 Created 27 3222 202 Accepted 28 3223 203 Non-Authoritative Information 28 3224 204 No Content 28 3225 205 Reset Content 29 3226 206 Partial Content 29 3227 300 Multiple Choices 30 3228 301 Moved Permanently 31 3229 302 Found 32 3230 303 See Other 32 3231 304 Not Modified 33 3232 305 Use Proxy 33 3233 306 (Unused) 33 3234 307 Temporary Redirect 33 3235 400 Bad Request 34 3236 401 Unauthorized 34 3237 402 Payment Required 34 3238 403 Forbidden 34 3239 404 Not Found 35 3240 405 Method Not Allowed 35 3241 406 Not Acceptable 35 3242 407 Proxy Authentication Required 35 3243 408 Request Timeout 36 3244 409 Conflict 36 3245 410 Gone 36 3246 411 Length Required 37 3247 412 Precondition Failed 37 3248 413 Request Representation Too Large 37 3249 414 URI Too Long 37 3250 415 Unsupported Media Type 37 3251 416 Requested Range Not Satisfiable 38 3252 417 Expectation Failed 38 3253 426 Upgrade Required 38 3254 500 Internal Server Error 38 3255 501 Not Implemented 39 3256 502 Bad Gateway 39 3257 503 Service Unavailable 39 3258 504 Gateway Timeout 39 3259 505 HTTP Version Not Supported 39 3261 T 3262 TRACE method 23 3264 U 3265 User-Agent header field 48 3267 Authors' Addresses 3269 Roy T. Fielding (editor) 3270 Adobe Systems Incorporated 3271 345 Park Ave 3272 San Jose, CA 95110 3273 USA 3275 EMail: fielding@gbiv.com 3276 URI: http://roy.gbiv.com/ 3278 Jim Gettys 3279 Alcatel-Lucent Bell Labs 3280 21 Oak Knoll Road 3281 Carlisle, MA 01741 3282 USA 3284 EMail: jg@freedesktop.org 3285 URI: http://gettys.wordpress.com/ 3287 Jeffrey C. Mogul 3288 Hewlett-Packard Company 3289 HP Labs, Large Scale Systems Group 3290 1501 Page Mill Road, MS 1177 3291 Palo Alto, CA 94304 3292 USA 3294 EMail: JeffMogul@acm.org 3296 Henrik Frystyk Nielsen 3297 Microsoft Corporation 3298 1 Microsoft Way 3299 Redmond, WA 98052 3300 USA 3302 EMail: henrikn@microsoft.com 3303 Larry Masinter 3304 Adobe Systems Incorporated 3305 345 Park Ave 3306 San Jose, CA 95110 3307 USA 3309 EMail: LMM@acm.org 3310 URI: http://larry.masinter.net/ 3312 Paul J. Leach 3313 Microsoft Corporation 3314 1 Microsoft Way 3315 Redmond, WA 98052 3317 EMail: paulle@microsoft.com 3319 Tim Berners-Lee 3320 World Wide Web Consortium 3321 MIT Computer Science and Artificial Intelligence Laboratory 3322 The Stata Center, Building 32 3323 32 Vassar Street 3324 Cambridge, MA 02139 3325 USA 3327 EMail: timbl@w3.org 3328 URI: http://www.w3.org/People/Berners-Lee/ 3330 Yves Lafon (editor) 3331 World Wide Web Consortium 3332 W3C / ERCIM 3333 2004, rte des Lucioles 3334 Sophia-Antipolis, AM 06902 3335 France 3337 EMail: ylafon@w3.org 3338 URI: http://www.raubacapeu.net/people/yves/ 3339 Julian F. Reschke (editor) 3340 greenbytes GmbH 3341 Hafenweg 16 3342 Muenster, NW 48155 3343 Germany 3345 Phone: +49 251 2807760 3346 Fax: +49 251 2807761 3347 EMail: julian.reschke@greenbytes.de 3348 URI: http://greenbytes.de/tech/webdav/